Free space on SSD

[emueyes]

I have seen numerous references to free space on an SSD having a dramatic effect on performance (like, every review I've ever read of an SSD...)

The Samsung 256G 840Pro I have seems particularly prone to this speed decrease it seems, once around 25% or less of the drives space is free.

I saw in passing a reference to some details written by Anand involving decreasing a partitions size, then re-partioning the freed space but not formatting it. I've tried to find that article, but can't, and can't find specific reference in the howto here. So for a very important bit of information -

What is meant by 'free space' on an SSD? I had thought that is a partition was < 75% full it was fine, or even better < 66% full. But is that what free space actually is? I'm particularly eager to know, as mentioned my 840Pro seems to suffer a lot from this condition.

I guess the next question is, if I've accidently gone over the limit, what is the best procedure to follow?

 

[Hellhammer]

http://www.anandtech.com/show/6489/playing-with-op

The 840 Pro is fairly bad in terms of IO consistency, so more OP will increase performance. Keeping parts of the partition free should be the same as TRIM will make sure the empty space is empty space for the SSD (although this will depend on the drive's garbage collection). Creating a partition smaller than the original is the most idiot-proof way as then there is no chance you'll go over the limit.

How full is your drive at the moment?

 

[emueyes]

Size
C : 99G 31% free Windows boot/system
D : 44G 61% free Programmes
95G unallocated

I really wish that I'd made a bigger Windows partition... I had thought at the time that would be plenty, but it's funny how often that estimate is wrong.

I try to keep C : clean, but some things install wherever they want or need to. Things aren't dire, but I'd rather they not get worse. The article never really makes a point about where this spare area is to be: The 95G unallocated is about 37% of the drive, can I then fill up the other partitions with impunity? Probably not. I'd think keeping 25% of each partition free would make more sense. But as the solution requiring most work is usually the right one:

Boot off live usb, store files on D : somewhere, delete D :, expand C :, recreate D : then shrink C : finally replace all files on D :

There're probably more convoluted schemes, but that one isn't bad for 4am

 

[Hellhammer]

Why do you even have separate partitions? With hard drives it made sense as the outer edge was considerably faster than the inner parts of the platter due to higher tangential velocity. However, there's no such thing with SSDs as NAND is evenly fast regardless of the placement of data.

Hence what I would do is remove the D totally and just expand the C. There's also no reason to keep as much as 37% OP when it comes to desktop workloads, so you should be fine with a 225-230GiB partition, which would leave 8-13GiB more for OP.

 

[Elixer]

Why do you even have separate partitions? With hard drives it made sense as the outer edge was considerably faster than the inner parts of the platter due to higher tangential velocity. However, there's no such thing with SSDs as NAND is evenly fast regardless of the placement of data.

Hence what I would do is remove the D totally and just expand the C. There's also no reason to keep as much as 37% OP when it comes to desktop workloads, so you should be fine with a 225-230GiB partition, which would leave 8-13GiB more for OP.

There are still many cases why you would want to partition the SSD. Main one being, you can just reinstall the OS if needed, without touching your other data.

 

[Hellhammer]

There are still many cases why you would want to partition the SSD. Main one being, you can just reinstall the OS if needed, without touching your other data.

You can move your data to a secondary drive before performing a reinstall. I see more cons than pros in partitioning SSDs. It was useful with HDs but now it just adds complexity and potential issues, such as running out of space on the Windows partition (and we all know Windows doesn't like that). Why partition when the same can more or less be achieved with folders?

 

[razel]

Wholly agree with Hellhammer with partitioning SSDs. The negatives of doing so FAR outweigh the simpicity.

 

[emueyes]

Why do you even have separate partitions? With hard drives it made sense as the outer edge was considerably faster than the inner parts of the platter due to higher tangential velocity. However, there's no such thing with SSDs as NAND is evenly fast regardless of the placement of data.

This's partly due to inertia, but also it forms the start of filing on the system. My hard drives have many, many partitions on them. The partitions can then be backed up or moved wholesale. Not much differently than a directory, OK.

I'd always had my working set of programmes and Windows on a different disk than media, say, for obvious reasons. That still holds true, I'm not storing 30G movies on the SSD.

Another thought has always been that if Windows needed reinstalling, then it would be much easier. This is still valid, I believe.

Another had been the concept of locality; having bits and pieces of installed programmes and Windows itself scattered everywhere I felt slowed things down with seek times. With SSDs that's obviously not an issue any more. However, as programmes are upated, they will tend to 'fragment; over the drive. And again, not an issue with near-0 seek speed, but if there are large files that have been split, then it will affect performance. Bit of a borderline case that one.

Large data disks I believe do need structuring. Hehe I wonder how many people remember the SUBST command and what it does. I use drive letters as my top level filing discriminator; T for temp, s for storage, and so on. There are also programmes need to look at drive letters and won't use a URI.

OK. I can't put a valid case for having partitions, at least on the boot/system disk. I still prefer it, it makes me comfortable. I'll be exploring the various filesystem manager available.

But. We still haven't answered the question, rather examined my '90s style of disk management. Does the 37% of the drive that has never been touched count as free space, as defined for the purpose of this discussion? Does it apply to all partitions if they are present? Are 'free spaces' somehow meant to be associated with in-use data areas, for eg being space that was left over from resizing existing partitions?

I think they're the questions I need to look at. Looking at my usage pattern, I have a very small working set of programmes in regular use, and a quite large set of programmes used infrequently, cue splitters, MKVMerge, things like that. I've got 17 gig of programmes, and some small amount of these which insisted on going onto the C drive. There's just not a lot there.

I'll still have a look at disk repartitioning software, but it would certainly appear that un - partitioning this drive would be the answer to this, be it a rather unexpected one, given that it goes against fundamental practices I've had for decades.

 

[Magic Carpet]

There are still many cases why you would want to partition the SSD. Main one being, you can just reinstall the OS if needed, without touching your other data.

I agree, especially when it comes to restoring, you just have several gigs of data at most. On desktop, I prefer to have a separate drive for data though, neater this way and waaaaaay speedier to move data back and forth

 

[KentState]

You can move your data to a secondary drive before performing a reinstall. I see more cons than pros in partitioning SSDs. It was useful with HDs but now it just adds complexity and potential issues, such as running out of space on the Windows partition (and we all know Windows doesn't like that). Why partition when the same can more or less be achieved with folders?

It would also seem to unevenly wear the drive if you limit the area that you write to. I know a drive will auto level the wear, but it will not intentionally move data that's been parked for a long time either. Basically limiting something like the 4-8GB swap file to 30% of the drive artificially by partitioning it off.

 

[F1shF4t]

It would also seem to unevenly wear the drive if you limit the area that you write to. I know a drive will auto level the wear, but it will not intentionally move data that's been parked for a long time either. Basically limiting something like the 4-8GB swap file to 30% of the drive artificially by partitioning it off.

Partitioning has no affect on wear leveling of the drive. SSDs will move static data around to get even wear. (Static wear leveling)

 

[emueyes]

Partitioning has no affect on wear leveling of the drive. SSDs will move static data around to get even wear. (Static wear leveling)

Would this then applied to the spare area? If a sector has been used 'too much' can a replacement be pulled from only formatted areas (within the same partiiton) or from partitioned but unformatted areas.

 

[Elixer]

You can move your data to a secondary drive before performing a reinstall. I see more cons than pros in partitioning SSDs. It was useful with HDs but now it just adds complexity and potential issues, such as running out of space on the Windows partition (and we all know Windows doesn't like that). Why partition when the same can more or less be achieved with folders?

You can still run out of space when you have one big partition, versus two (or more) partitions, so I think that is a moot point.
Everyone should know that once a SSD gets within 10% space left, it is time to either upgrade to a bigger SSD, or make the partition bigger.

I just guess it depends on what your backup program does. Most all free ones just clone the whole partition.
Then when you need to restore, you just re-image the partition from backup, and usually, it is much faster to clone & restore as well.
Simple and sweet.
Take for example, you have steam/origin installed, and you have all files on your SSD C: partition. You then would image the whole partition with all that data, instead of just the OS partition, which is usually the only thing that messes up.
That takes up much more time to do.

 

[Hellhammer]

OK. I can't put a valid case for having partitions, at least on the boot/system disk. I still prefer it, it makes me comfortable. I'll be exploring the various filesystem manager available.

You can still have partitions if that's what you want. I was just trying to explain why they are no longer beneficial but I understand why you want to do it if that's what you've always done. Sometimes habits overcome logic.

But. We still haven't answered the question, rather examined my '90s style of disk management. Does the 37% of the drive that has never been touched count as free space, as defined for the purpose of this discussion? Does it apply to all partitions if they are present? Are 'free spaces' somehow meant to be associated with in-use data areas, for eg being space that was left over from resizing existing partitions?

Free space is free space, regardless of it is formatted or not. The only difference is that if the space is formatted, then erasing the non-used LBAs is up to the SSD and its garbage collection. Some drives may rely heavily on idle GC, which means they may not erase the data when TRIM command is sent but later when the drive has nothing else to do. That can be an issue if your workload is heavy, i.e. meaning no idle time for the SSD. Unallocated space cannot be accessed by the OS, so it will never be filled.

The drive itself doesn't care about partitions, hence free space is partition-independent. The whole purpose is to ensure enough empty blocks so when a write request comes in, the drive can immediately write it to NAND instead of first reading the block, then erasing and finally writing.

It would also seem to unevenly wear the drive if you limit the area that you write to. I know a drive will auto level the wear, but it will not intentionally move data that's been parked for a long time either. Basically limiting something like the 4-8GB swap file to 30% of the drive artificially by partitioning it off.

That's exactly what wear-leveling does.

You can still run out of space when you have one big partition, versus two (or more) partitions, so I think that is a moot point.
Everyone should know that once a SSD gets within 10% space left, it is time to either upgrade to a bigger SSD, or make the partition bigger.

Sure you can run out of space on any drive, no matter how it's partitioned. The point is, the likelihood of running out of space is bigger when the drive is partitioned. It's unlikely that you'll fill the partitions evenly. That may result in a situation where your other partition is full while the second partition still has empty space. Had you not partitioned the drive, that space would be more usable. Of course, this whole thing only matters because Windows goes nuts if you have very little space left and software is always installed to the C drive by default.

I just guess it depends on what your backup program does. Most all free ones just clone the whole partition.
Then when you need to restore, you just re-image the partition from backup, and usually, it is much faster to clone & restore as well.
Simple and sweet.
Take for example, you have steam/origin installed, and you have all files on your SSD C: partition. You then would image the whole partition with all that data, instead of just the OS partition, which is usually the only thing that messes up.

I would argue that there's not much point in resintalling and then re-imaging. There's a good chance that what caused the issue in the first place will be moved back with re-imaging. Basically, you could achieve the same with a repair install which involves no re-imaging at all.

If you want to start fresh, then you don't move all the crap back

That takes up much more time to do.

I don't think this is much of an issue with SSDs since they are smaller. With a 3TB HD that is full, then I get the point as transferring the data alone takes hours, but transferring e.g. 256GB of data can take less than an hour (assuming we're not limited by something like USB 2.0 here).

 

[emueyes]

The drive itself doesn't care about partitions, hence free space is partition-independent. The whole purpose is to ensure enough empty blocks so when a write request comes in, the drive can immediately write it to NAND instead of first reading the block, then erasing and finally writing.

This is the point that's being skirted around a bit, I think. We say a drive has '7-10% overprovisioning' that is, space that is never available to the user, if I understand any of this correctly. And we want to increase that to 20 or 30%. I can understand that it might be quite a specific moment when a drive becomes full enough that write-propagations start happening, causing what ends up being an avalanche, but that would surely be specific to the partition, be it one large one or two small ones, and would appear to be something different than the 'spare' space wanted by the drive itself. We can't store files on unformatted space. Or, is that what you are saying, that the ssd firmware temporarily writes a file to any spare space it can sometimes, including unformatted areas?

This has convinced me that the two partition I use is not the best I can do. For a start, there is that rather large chunk of drive that is doing nothing - unless it's used by the drives firmware.

The quality of software I saw when I got my first drive (I have a Samsung 830, too) and migrated things around was great. Hopefully getting all of my installed stuff moved into the C : partition won't be too dramatic; ironically enough exactly the same problem of reinstallation of programs with a reinstall of Windows on a 2 partition system.

 

[hipshooter]

Sorry, for barging in on, here. But I also, am perplexed about this concept of 'free space' that was the initial issue.

Does this mean that a SSD sees a partition as a non-defined (in terms of form or shape) item, that is only fixed in size and when it receives a write request it can place the actual location of that partition a little to the side to accomodate that data and place former data that is to be considered 'garbage' outside the partition? Not deleted nor rewritten just like relegated?

Thus, the benefit for the SSD to have OverProvisioning at all, is that it can relocate and dislocate at will because of this OverProvisioning?

Sorry for being philosophical. . .

 

[F1shF4t]

This is the point that's being skirted around a bit, I think. We say a drive has '7-10% overprovisioning' that is, space that is never available to the user, if I understand any of this correctly. And we want to increase that to 20 or 30%. I can understand that it might be quite a specific moment when a drive becomes full enough that write-propagations start happening, causing what ends up being an avalanche, but that would surely be specific to the partition, be it one large one or two small ones, and would appear to be something different than the 'spare' space wanted by the drive itself. We can't store files on unformatted space. Or, is that what you are saying, that the ssd firmware temporarily writes a file to any spare space it can sometimes, including unformatted areas?

This has convinced me that the two partition I use is not the best I can do. For a start, there is that rather large chunk of drive that is doing nothing - unless it's used by the drives firmware.

The quality of software I saw when I got my first drive (I have a Samsung 830, too) and migrated things around was great. Hopefully getting all of my installed stuff moved into the C : partition won't be too dramatic; ironically enough exactly the same problem of reinstallation of programs with a reinstall of Windows on a 2 partition system.

I think you should have a look at some articles on how SSDs work. This old AT one is good to start: http://www.anandtech.com/show/2738/5

Simply put on a SSD Logical Locations(What you see in OS) != Physical NAND locations. The SSD controller keeps a map which translates the Logical addresses as seen by the OS to where it stored them on the NAND. The controller can't see partitioning all it knows is whether a particular Logical address has been allocated and whats written to it. Similarly the OS can only see the Logical addresses that the SSD controller shows it.

What this means is that while you might see your partitions and files being shown in specific places in reality they are in millions of tiny fragments stored randomly in NAND. As you do more writes the controller will move things around in NAND to wear level the cells and update the map, logically the OS will never see a difference.

Few Points:
- SSD has more NAND than can be logically allocated, this is called spare area.
- If nothing has ever been written to a logical address it has not been written to NAND and therefore for the SSD controller this is free NAND to play with. It's essentially what is achieved by over-provisioning.
- Once you write into a logical address the controller has to keep that data or you get data loss. The controller has no understanding of the file system so until it is told that it can erase it, it will keep it. Two ways it will know this, one you write new data to the same logical address (it will mark the old location in NAND as stale and write to a new NAND location and update the map) or by using Trim.

On a different note, what's your workload on the SSD? Unless its fairly heavy you don't even need to think about over-provisioning. Just partition the whole drive as you like (makes no diff one or many partitions) and you're done.

BTW: if I'm wrong in anything above feel free to correct me

 

[KentState]

Partitioning has no affect on wear leveling of the drive. SSDs will move static data around to get even wear. (Static wear leveling)

That's good to know. SSD has always been a commodity device so wear leveling has never been a concern to me. Interesting to see the various ways manufacturers deal with wear.

 

[emueyes]

Simply put on a SSD Logical Locations(What you see in OS) != Physical NAND locations. The SSD controller keeps a map which translates the Logical addresses as seen by the OS to where it stored them on the NAND. The controller can't see partitioning all it knows is whether a particular Logical address has been allocated and whats written to it. Similarly the OS can only see the Logical addresses that the SSD controller shows it.

Yeah, I've seen the translations done by old IDE controllers, this seems quite similar.

So, the controller can choose any unused block, including unused/unformatted ones, for writing when it needs to?

My load level is very light. but neverthless I don't want my 840Pro falling off that performance precipice, and wish to find out how to do so. Just using a single partition seems to be the easiest thing I can do.

 

[Franzi]

For the Samsung 840 Pro 256GB, can I just shrink my current partition by 25% with the Windows disk management tool to get the additional OP space afterwards or will left-over data remain in the unallocated space and prevent it from working as OP space? I don't really want to install Samsung's Magician software just for that.

 

[Phynaz]

My load level is very light

There's zero reason for you to over-provision then.

 

[emueyes]

My load level can be very light and yet still fill 99.9% of a partition. Since I've got what is by all accounts, a rather good SSD, like any piece of computer gear I own, I'd like it to be running at peak performance. In this particular case, the 840 Pro has a tremendous performance hit when it goes over a certain threshold of space used, hence my efforts to determine just what is meant by 'free space', and establishing the best strategy for using the drive.

 

[emueyes]

@ Franzi I didn't find Samsung's Software Magician to be particularly good, despite the reviews. It's only real use is firmware updates. I'd use any of half dozen alternatives for partition management.

 

[emueyes]

An update. It seems that this issue has been debated for quite a while. Looking back at Anand's original article http://www.anandtech.com/show/6489/playing-with-op


B3an - Tuesday, December 04, 2012 - link
I'm not sure if thats what the article is saying... But either way i'd also like to know for sure if simply partitioning an SSD to have about 75% of usable space will increase I/O performance (even over a new drive with hardly anything on it).

Think the article needs to make this more clear...

Anand Lal Shimpi - Tuesday, December 04, 2012
http://www.anandtech.com/comments/6489/playing-with-op/283816

Updated with more info on this. In short, yes with the controllers used here that's all you need to do to allocate more spare area.



I may have configured my drive in an optimal way, completely by chance. It has a sizeable unpartitioned space on it, never partitioned or formatted.

 

[Phynaz]

My load level can be very light and yet still fill 99.9% of a partition.

How much you fill a partition doesn't matter. It's the level of constant writes without "rest" time for the drive to do garbage collection.

If your load level is very light then by definition there is no reason to over-provision.

From the article you linked:

Next I kicked off a 4KB random write workload across all LBAs at a queue depth of 32 using incompressible data.

Is that your workload? If so then over-provision. But the user that can sustain minutes of incompressible writes during normal operation is a rarity. Don't confuse torture tests with normal operation.