SSD Wear Leveling in Unallocated Space

Question

There are many questions related to wear leveling. Seems too many of us cannot wrap our heads around this somewhat new technology since we have been working with mechanical disk drives for so long.

The consensus is free space, i.e., unused space, will be utilized to "level out" the usage so individual cells don't drop out as quickly as they would without this shifting utilization.

I did find one article that suggested the SSD wear-leveling feature is not interested in partitions; that it will utilize any cells on the unit that are available for utilization. But it was vague and failed to answer my question.

My question is, will unallocated space be utilized as well as any other partition for the wear-leveling feature?

Additional information: The purpose of leaving some space is in the event of a system image restoration to a smaller drive. Some backup software disregards free space so it would not be a problem, except in the case of bit-by-bit images, which include the free space so the restore procedure will fail. The instant Windows setup is a 500GB SSD which only uses 100GB since all files are stored elsewhere; in other words, my system drive. I would prefer to replace with a 240 to 250GB drive and not worry about possible sizing problems. I use both Acronis TIH and Windows built-in System Image software. I have not been setting Acronis for bit-by-bit, and I'm not sure what Windows does.

Thank you all in advance for any comments, suggestions or pointers to an definitive answer.

Answer 1

My question is, will unallocated space be utilized as well as any other partition for the wear-leveling feature?

Yes. But the way you are asking your question implies a wrong understanding of SSD operation.

The job of the firmware of the drive is to manage storage units, disregarding of its use. That means disregarding if the drive is partitioned or not, formated or may be has some proprietary organisational structure.

Stuff like partition, file system and unallocated space is handled by the operating system and not the firmware of the drive.

Even if one could program a firmware that is able to read partitions and file systems it is not the purpose of the firmware to do that and it is kind of dangerous.

The ATA TRIM command is a door between operating system level and firmware level. Indicating sectors that are not in use anymore gives the firmware a chance to delete their content before the operating system issues a write command to those sectors sometime in the future.

By informing the firmware about those sectors very early, the next write command to this sectors does not require the firmware to delete the sectors before writing the new content, because the firmware had the time to delete those sectors before.

This way you save the time needed for deletion of sectors which is a prerequisite before writing new content on them.

Answer 2

You're correct that SSDs don't understand partition tables - for them these are all just bytes - so they can't reliably tell which space should be considered unused. Once a sector has been written to, the SSD must consider it used.

That's why TRIM is a thing. The computer can send a "trim" command to mark an area as unused. This implies that SSD's understanding of which sectors are in use goes beyond just knowing if they belong to a partition. Even regions belonging to a partition, with a valid filesystem on them, can be trimmed to reclaim sectors occupied by now-deleted files.

Your OS most likely trims the drive periodically (it's not done immediately for performance reasons).

Trimming doesn't erase data immediately. Firstly because that's oftentimes impossible: data on SSDs is organized into erase blocks and every update to data stored in such block requires rewriting an entire block. As a consequence, an entire erase block must be trimmed to actually be considered unused. Secondly because SSDs have limited lifespan measured in number of writes. Actively destroying unused data would unnecessarily consume write cycles and shorten drive's lifespan. Instead, the drive will just consider data in such block obsolete. It will be available for overwriting for wear leveling and data won't be actively preserved.

It may be worth noting that TRIM may have security implications if you're using full disk encryption. Properly encrypted disk looks like random gibberish, even in areas where no data is stored. Trimming may thus reveal empty regions because this gibberish may turn into actual zeros, or maybe some other recognizable pattern. Whether that is a problem is up to one's informed judgement.

---

Please keep in mind that with the newer GPT partitioning scheme, a backup partition table header is stored at the end of the disk. Writing a full image to a smaller drive will thus cut it off. It may be a good idea to recreate it post-restore with some partitioning tool.

Answer 3

unallocated space

Whether a (range of) logical block(s) is marked as allocated in the partition table (or in other words, part of a partition) is NOT directly related to whether it is considered as "used" / "occupied" / "mapped" (to actual storage).

It's pretty much like on filesystem level, not every logical block of a partition (or drive, if "partitionless") is deemed used either. Yet what the filesystem has keep track / record of is NOT directly related to what the firmware of the drive does either, which is why it needs to be "notified" by the OS (by the means of "TRIM") to be aware of which logical blocks can be deemed "free" (as in, the data it consists of can be considered as "forgettable").

Such notification can be triggered upon file deletion (e.g. discard mount option in Linux, or delete notification "behavior" in Windows), periodically as per the current record in the filesystem on a partition/drive (e.g. fstrim in Linux), or a "filesystem-neglecting" (i.e. whole partition/drive) "TRIM" (e.g. blkdiscard in Linux).

If you have some idea about programming, you can also see logical blocks on a drive (not necessarily SSD anymore these days) as pointers. TRIM is a bit like setting a (bunch of) pointer(s) to NULL (which is not exactly the same thing as freeing the "actual" memory either, just like TRIM does not erase a storage cell right away). A partition is nothing but a collection of logical blocks, which is in turn just a means to tell a filesystem which and how many at max it could use. (The "postition" of a logical block, or the contiguous nature of the blocks in a partition, does not reflect where/how the data is placed behind the scene.) A filesystem driver could tell the OS which of the "pointers" "allocated to" a filesystem can be set to NULL, but the filesystem itself is not responsible of keeping records of that.

"Allocating" space as a partition in a partition table is nothing but adding a record entry to it that is composed of the zero-based addresses of a starting and ending logical block (and a few other information, of course). It does NOT tell the firmware to "set" all the blocks within the range "to NULL". (However, in Linux many of the mkfs utilties by default does. Not sure about Windows but AFAIK it does not trigger a full partition/drive TRIM upon formation.)

P.S. For you cloning question, different cloning software can have different cloning manner. If the software do it a in partition-by-partition manner (i.e. cloning only the partition table and all the partitions, but not the "unallocated spaces"), then it will not have problems regarding drive size as long as the "allocated"/partitioned space is not larger than the destination drive. However, it could also be doing it in a "partition-unaware" (i.e. full drive block-by-block) manner. In that case it will have problem if the destination drive size is smaller than the source. Since either of these manners will clone all the logical blocks in concern (i.e. "filesystem-unaware"), so all the corresponding blocks will be deemed "occupied" by the firmware on the destination drive regardless of whether they are so on the source drive, until you maybe run fstrim on the destination drive. (As you might have noticed, there's not exactly a way to "get" / "read" whether a certain block "has been set to NULL". Even if on a specific drive a block will "read zero after TRIM", it does NOT imply "read zero means TRIM'd" or "write zero is equivalent to TRIM".)