SSD partitions and scratch space

[Essence_of_War]

I think I understand how this works, but I just wanted to confirm it.

Suppose I have need of a high-performance scratch disk for video/photo editing.

Suppose that I have a shiny new drive, like a 480 GB SanDisk Extreme II.

If I partition it thusly:
Partition 1:~300 GB OS/applications
Partition 2: ~100 GB scratch space
And then leave the ~80 GB remaining un-allocated as over-provisioning.

The SSD controller will take care of all of the wear leveling, write-spreading etc over the whole capacity of the drive, so even if I hammer that scratch space with a ton of photo/video editing work, I won't "wear out" that particular 100 GB, right?

 

[Elixer]

Yeah.

 

[Blain]

If you want the best performance...
The scratch disk should be on a separate SATA channel, not the same channel as the OS & programs.

 

[Cerb]

For a single drive, yes, the SSD will take care of it. But, do your programs need raw access to an unformatted partition? If not, no partitioning should be necessary.

The best performance would be from a RAID 0 (splitting IO just wastes potential speed your OS/Apps SSD might be able to give you, if combined with the other one); made up preferably by 240GB and up drives, today.

 

[imagoon]

Personally I don't see any value in leaving the much space as scratch + the 33GB of spare space already allocated on the drive. If for some reason TRIM is not running or even being ignored, it will never free more than the 33GB of spare area anyway.

 

[Cerb]

^ That too. The Extreme II is, like most modern SSDs, good at retaining performance with TRIM, so just keeping it not near full most of the time will do the trick.

 

[Essence_of_War]

Cool, Ok, thanks for the input, everyone.

 

[imagoon]

^ That too. The Extreme II is, like most modern SSDs, good at retaining performance with TRIM, so just keeping it not near full most of the time will do the trick.

Even near full, with 7% slack on a 480GB drive, I would think most people would be fine. The big question is "will I write 33GB of data to this drive randomly as fast as it can accept it" if yes, then normally there is a tool out there to adjust the slack space which is a better solution than leaving empty space at the end. Reason being that if the drive is powered off with a table full of TRIM commands in the queue, during the next boot up it will be lost so the sectors never get TRIMed. This will eventually leave you with 80GB of random junk because the drive doesn't know it is junk and the 33GB of slack you started with.

 

[Cerb]

Even near full, with 7% slack on a 480GB drive, I would think most people would be fine. The big question is "will I write 33GB of data to this drive randomly as fast as it can accept it" if yes, then normally there is a tool out there to adjust the slack space which is a better solution than leaving empty space at the end. Reason being that if the drive is powered off with a table full of TRIM commands in the queue, during the next boot up it will be lost so the sectors never get TRIMed. This will eventually leave you with 80GB of random junk because the drive doesn't know it is junk and the 33GB of slack you started with.

And, if you can stand the corrected interface(s), that would be good reason for Windows 8, with scheduled full-pass TRIMs instead of defrags, in case a drive behaves that way (of course, were TRIM made deterministic to begin with...). Though, it's probably wasted concern either way, as video and photo editing are surely doing mostly large/sequential writes, which are going to be easy on the SSD, anyway.

Also, it's got up to about 12.5% slack, for nearly 70GB, right from the factory. The Extreme II may use SLC mode caching, so it's not a fixed amount, but with 512GB total NAND, and keeping so much of it...