[qiqitori]

Not 100% sure what you are replying to, and not sure what you meant by "safer", but this may help:

The actual physical address on the storage chip and the physical address from the operating system's perspective don't have much to do with another. For harddrives, "un-partitioned space" means that there is a physical "chunk of metal" that is unused.

However, that's not the case for SSDs. SSDs dynamically remap "OS-physical" block numbers to whatever they want. (Preferably addresses that have never been used before or that have been discarded/trimmed. If there aren't any available, perhaps to the address that was previously used for the same block number.)

[mikewarot]

>Not 100% sure what you are replying to, and not sure what you meant by "safer", but this may help:

I'm replying to the whole of comments on this article. The write amplification problem goes up as the number of "free" sectors/blocks goes down. Many solutions have been presented that don't allocate X% of the hard drive... but I'm not sure than any of them let the hard drive's SSD controller know they aren't allocated.

For that to happen, the OS has to have TRIM support, AND the block in question has to be on a volume that the OS is managing.

My worry is that if you have a blank partition, it's not being actively managed by anything, and thus isn't going to be TRIMed, and thus the SSD doesn't know the blocks are free for use.

Thus, leaving an unpartitioned area isn't going to help.

[rdc12]

The drive can infer that the LBA hasn't been mapped, since it won't be present in the FTL, there is no need for the OS to inform the drive of this.

[mikewarot]

How could the drive know? TRIM commands are the only way to "free" a sector/block for writing. The drive might have been tested during setup, so the block might not be empty any more.