Write to fast drive and then move to slow drive?

[ttnicky]

This question is purely academic for people smarter than me. I have a couple of super fast SSDs for normal PC operation, and then I have some slower HDDs for mass media storage. When using MakeMKV to rip a disc, does it matter if I first rip to the fast SSD and then move to its final destination on the slower HDD, or just rip straight to the slower HDD? I'm thinking it is probably faster to just rip directly to the slower HDD because the file is only being written once, but that is based on the assumption that MakeMKV's writing and PC's moving the file are the same operation. If how MakeMKV writes the original file is different than how Windows moves a file, I could see there might be a benefit to writing to a really fast drive and then moving after.

I should clarify that my process is make backup to SSD and then write movie files from the backup to either fast SSD (and then move to HDD) or write movie files directly to HDD.

[dcoke22]

The part of your workflow that reads from the optical disc and writes it to computer storage is limited by the read speed of the optical disc. In a scenario where you're reading from the optical disc and writing your 'final' .mkv file, you could write it to your (relatively) slow HDD and be fine.

If, however, your workflow is to create a backup and then create .mkv file(s) from the backup, MakeMKV will probably be limited by your storage speed. I would expect MakeMKV to create a .mkv file from a backup faster if that stuff is on a (relatively) fast SSD than if it is on a (relatively) slower HDD.

You could test this by creating .mkv files from a backup using the various combinations of source and destination drives. If you truly want a fair comparison, you'd likely have to reboot between runs since your computer will likely be caching some of the files in RAM on subsequent runs (depending on how much RAM is in your machine).

Personally, I have a SSD based volume that is my work area for ripping discs with MakeMKV. Once I'm satisfied with them, they get transferred to long term storage on HDD (in a NAS on the network). My SSD work area is a separate SSD than the ones the rest of my computer runs on. The constant reading and writing of giant files to the SSD is relatively abusive to the SSD and will likely wear it out much faster than typical computer usage.

[ttnicky]

Thanks for the information. It definitely writes from backup much faster to my SSD than my HDD, but then I have to move it to the HDD, so I figured it probably ends up the same if I just write the file from backup to the HDD. I was not aware of how damaging the large files are to an SSD. I'll be watching for that in the future.

[dcoke22]

Large files aren't inherently bad for SSDs. It is the constant writing of doing a rip, deleting it, then doing another rip. Each cell of a SSD can only be written to a finite amount of times. The controller on most SSDs has a wear leveling algorithm where it keeps track of which parts of the SSD have been written to more often so it can write files to the less used parts of SSD so that it 'wears' evenly. Eventually, however, the cells start to become too unreliable and are no longer used. For typical computer usage, a SSD will last as long as or longer than the computer. It isn't a thing most people have to worry about. But if you're hammering it by writing backups, then .mkv files, copying them off and then deleting them just do it all over again a 1000 times, you can see how you'll 'wear' the SSD faster than if you weren't doing that stuff.

Basic SSDs are fairly inexpensive and fast enough to be useful. This is why I use an inexpensive SSD as my 'workspace' for this stuff. I get the benefits of the speed of the SSD while keeping the wear this workload causes away from the more expensive (and faster) SSDs my computer runs off of.

If you have a Samsung SSD, the Samsung Magician software can show you how far along in the wear lifecycle you are. Other brands may have software that can do the same.

[drxenos]

A HDD is already magnitudes faster than an optical drive. Writing to something even faster isn't going to make the ripping go any quicker. The optical drive is the bounding resource in this situation.

[ttnicky]

It's not the ripping I'm asking about, but writing the movie files from the backup. I could have been more clear in my OP.

[shisha0505]

The limiting factor is the speed of your optical drives. They are waaay slower than any modern HDD.
So yes, ripping directly to HDD will save you time
At the moment i'm in the process of backing up all my BluRays.
I have two optical drives ripping directly to an external 18TB HDD.
The HDD doesn't even come close to its speed limit even with both optical drives writing parallelly.
So no, there is no need to write to SDD first.
Besides that: why load extra "wear and tear" to the SDD with unnecessary reading and writing processes?

[dcoke22]

The limiting factor is the speed of your optical drives. They are waaay slower than any modern HDD.
So yes, ripping directly to HDD will save you time
At the moment i'm in the process of backing up all my BluRays.
I have two optical drives ripping directly to an external 18TB HDD.
The HDD doesn't even come close to its speed limit even with both optical drives writing parallelly.
So no, there is no need to write to SDD first.
Besides that: why load extra "wear and tear" to the SDD with unnecessary reading and writing processes?

I first rip to a decrypted backup and then make .mkv files from the backup. This makes it easier for me to capture all the extras on the disc and get all the commentary tracks and subtitle tracks labeled appropriately. In this scenario, having a backup on a SSD makes a big difference since the creation of the .mkv files is limited by storage speed.

[shisha0505]

yeah, sure.
If you want a full backup plus a *.mkv version of your BluRays then first backing up to a SSD or fast HDD and then ripping from that backup to a SSD or HDD is of course the fastest way.