0

This answer explains that the actual locations of files on an SSD are not related to the perceived locations, and will change every time the file is updated.

What I wonder is does this apply to partitions and filesystems too?

If I create a partition 1000 times on an SSD and format it 1000 times, will the partition and filesystem data be written to different parts of the SSD every time?

What about a filesystem within a container file on a filestem on an SSD? Will the container file fragments be moved on the SSD every time a file within it (or even just a timestamp) is updated?

1
  • "will the partition and filesystem data be written to different parts of the SSD every time?" -- Using the exposed interface of the SSD, the answer is "no", the same LBAs will be used if you repeat the same commands. If the FTL maps those LBAs to different pages of the NAND flash (which it will), then you will never know. Your question is poorly worded, as if the SSD has only one layer of addressing.
    – sawdust
    Commented Oct 29, 2021 at 6:44

2 Answers 2

1

What I wonder is does this apply to partitions and filesystems too?

There are no files, partitions and file systems on an SSD, from the SSD controller’s standpoint. There are blocks with their LBAs (Logical Block Addresses). The wear-leveling algorithms and the underlying virtual-to-physical block number mappings apply to all data, no matter what the user of the SSD might call them. Some blocks happen to hold file system metadata. Other blocks happen to hold file data or partitioning metadata (such as GPT (if used) or LVM (if used)); the SSD neither knows nor cares which is which.

If I create a partition 1000 times on an SSD and format it 1000 times, will the partition and file system data be written to different parts of the SSD every time?

Not necessarily every time, but mostly yes, for the sake of wear leveling.

Additionally, physical block migration can sometimes affect blocks that have nothing to do with the ones being written. Consider, for example, what should happen when (say) 99% of the SSD is “full” (i.e. not discarded / trimmed (i.e. considered actual data)) and lots of write operations happen in the 1% of LBAs that the file system considers free or keeps reusing. If the SSD’s controller did not use a wise enough block (re)mapping algorithm, i.e. if that 1% of LBAs kept pointing at the same 1% of physical blocks all the time, then that 1% of physical blocks could go bad relatively quickly, effectively reducing the SSD’s life expectancy by a factor of 100 (in the sense of TBW, Total Bytes Written). In such case the controller may decide to swap frequently modified LBAs’ physical blocks with infrequently modified ones’ physical blocks, in order to keep physical block wear (more) even.

3
  • 1
    "LBAs (Linear Block Addresses)" -- The "L" stands for logical.
    – sawdust
    Commented Oct 29, 2021 at 6:40
  • @sawdust You’re right. I fixed that. There was a context in which it was called linear, to reflect the transition of spinning disks from multi-dimensional C/H/S addressing to a one-dimensional block address space. But that has no counterpart in the realm of SSDs and it looks like logical has (indeed) taken over the interwebs. Good catch. Commented Oct 29, 2021 at 10:47
  • I still have a hardcopy of an old version of the ATA spec pre-SSD, and it specifies Logical Block Address. There never was "Linear" unless someone made it up, nor was there any change as you claim. CHS addressing is based on the physical geometry of the drive. The new scheme used a block address that is assigned, e.g. logical, that doesn't rely on physical location.
    – sawdust
    Commented Oct 29, 2021 at 18:53
0

The SSD will only see WRITE commands the OS send. If you create/delete a partition 1000 times, the only blocks which will be changed (1000 times), are the blocks which contains the partition table. If you « reformat » a partition, the metadata of the partition will be rewritten too (root directory, free block list…), not the whole partition.

I don’t understand your idea of container. If they are just volume managed by a volumes manager (LVM on Linux ?, Geom on FreeBSD ?), there are few metadata (like an enhanced partition table), then a change should not imply many reallocation and there implied wearout.

4
  • When a timestamp in a filesystem within a container file is changed, the container file itself will have been changed, so does this mean the container file will be rewritten every time, or only the small timestamp data?
    – EmmaV
    Commented Oct 28, 2021 at 19:43
  • I guess the container is something like a .vdi file (you should really precise what you mean by a container). If you access a file inside it, you will change its access time, and, since your virtual host modify the underlying file, the file will be written, perhaps some metadata (access tile), and even more with some Copy On Write file system like ZFS. But not the whole file will be written. You will not have a GB of data because you read a tiny file. WRITE commands are likely to be delayed, then multiple change to a metadata could be summed up by a single WRITE. Commented Oct 28, 2021 at 20:10
  • @EmmaV it depends entirely on how the file is accessed or written by whatever program you are using. If the program seeks to a specific part of the file (container) and then writes 1 block of data then only one block of data on disk will change. If the program deletes the file and then essentially dumps an entirely new blob of data in place then the whole file data is rewritten. Which thing happens depends entirely on the program, what kind of data it is using and if it can write files on a block by block basis. Virtual machine (and disk images in general) lend themselves to block writing.
    – Mokubai
    Commented Oct 28, 2021 at 20:16
  • "When a timestamp in a filesystem within a container file is changed, ..." -- The LBA (i.e. a block or sector's worth of data) that includes the timestamp data would have to be (re)written. The rewrite of a LBA will cause the FTL to use a pre-erased flash block to replace (by remapping) the old block.
    – sawdust
    Commented Oct 29, 2021 at 6:58

You must log in to answer this question.

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