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.

  • 1
    I would assume that when you delete a partition the OS sends matching TRIM commands to the SSD marking the sectors used by the partition as deleted and thus these sectors get back to the wear-leveling algo.
    – Robert
    May 5, 2022 at 14:09
  • If you're worried about restoration, because the same physical cells are no longer in use due to wear, or because they've been allocated to other use, most disk imaging software I know of, such as Macrium Reflect, allow the SSD firmware to correctly put the bits where they should go at that point in time. See forum.macrium.com/10495/SSD-Backup-and-Restore , forum.macrium.com/33161/Full-Image-Restore-to-SSD-Wear-Tear May 5, 2022 at 15:10
  • What is Acronis TIH? Your "additional information" sounds as if you don't know how backup software behaves. I see no connection between your question and the "additional information".
    – r2d3
    May 5, 2022 at 18:37
  • TIH=True Image Home, as in True Image Home Edition, or the "I really don't know what I'm doing edition". I believe my original question has been answered. The discussion began to tangent to backup situations--my apology.
    – ITPhoenix
    May 5, 2022 at 20:49

3 Answers 3


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.

  • 2
    I think OP is actually aware that SSDs don't bother with disk structures ("I did find one article that suggested the SSD wear-leveling feature is not interested in partitions"). Their question is (paraphrasing) "if that's the case, how does SSD know what's unused?"
    – gronostaj
    May 5, 2022 at 14:34
  • 1
    "...your question implies a wrong understanding of SSD operation." Your inference is correct. @r2d3: The way you worded your answer is the one that I was able to comprehend easily.
    – ITPhoenix
    May 5, 2022 at 20:21
  • Thanks alot. Makes me happy! :)
    – r2d3
    May 5, 2022 at 21:46
  • 1
    Another important feature of the trim command is that the drive won't waste effort moving around useless data when it relocates blocks. If an OS had abandoned the data in sector 24601 but didn't tell the drive about it, and the drive needed to reclaim some storage on the block containing sector 24601, the drive would need to copy the data from that sector somewhere else. If, however, that sector has been trimmed, then the drive will know that it shouldn't bother copying that sector, which will both save work and mean that the reclaimed block will have an extra free sector.
    – supercat
    May 6, 2022 at 23:10

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.

  • Thank you for the comment. I perceive the consensus in this post is SSDs are partition ignorant as far as trim is concerned; thus, there is no such thing as "end of the disk"?
    – ITPhoenix
    May 5, 2022 at 19:52
  • 2
    @ITPhoenix: An SSD has some logical size, like 224GiB. The computer can access them by sector number, from 0 .. n-1, where n is the number of valid sectors. Access beyond that would return an out-of-range error from the SATA or NVMe command. So there very much is a last sector, just like any file on disk has a "last 4096 bytes". Of course we're talking about logical sectors; the virtual storage the SSD exposes over SATA, not the physical sectors they're remapped onto. May 6, 2022 at 5:06
  • 1
    @ITPhoenix: For every logical sector, including the last one, its data is in some physical sector at any given time, unless it's been TRIMed so the SSD knows there's no data there to preserve. IDK what you're talking about in the rest of your comment; all I'm saying is that there is a last sector of the logical array of sectors that is visible from outside the SSD. That's the space your partition and use. Wear leveling / flash remapping is purely internal to the SSD. (Although the fact that it's done is what makes it ok for the OS to rewrite a few logical sectors repeatedly.) May 6, 2022 at 14:02
  • 1
    @ITPhoenix Early bad sectors won't be detectable for the OS at all during format. They will only appear in SMART parameters and you should treat such drives with caution, because in some cases the damage will keep getting worse. If bad sectors can be detected during a format it's already too late: there were so many that the drive has ran out of spares and it's basically a ticking timebomb. If you're going to format such drive and start from scratch, just get a new one and save yourself the headaches of migration later. But if SMART looks good there's no need to slow format.
    – gronostaj
    May 6, 2022 at 20:22
  • 2
    @gronostaj Samsung Magician reports all OK including SMART. Crucial does not recommend slow format as it unnecessarily adds wear to the drive since it performs a full read/write cycle. crucial.com/articles/about-ssd/…
    – ITPhoenix
    May 7, 2022 at 0:55

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".)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .