At the SSD level, the drives are actually doing block management, not file management. You still need a filesystem to store metadata, manage the layout of the d

At the SSD level, the drives are actually doing block management, not file management. You still need a filesystem to store metadata, manage the layout of the data, etc. An example of something that a SSD's controller does that the operating system/filesystem doesn't have to worry about is managing bad blocks. If the SSD detects a bad block, it will replace it with a working block and update the data used by its flash translation layer to move the blocks around. This is completely opaque to the operating system; as far as it knows its underlying storage works exactly the same (until there are so many bad blocks that the drive can't keep up this convenient deception). An example of something a filesystem does that the SSD doesn't provide is storing operating system-specific file metadata, such as permissions, creation times, multiple data streams, directory layouts, etc. SSDs deal only in blocks of data, not arbitrarily-sized units, nor metadata. The reason that this behavior isn't more tightly-integrated is because some of the details of managing the underlying flash blocks tend to be specific to type of flash, or even different models of flash. For example, the article mentions QLC flash becoming mainstream - we're finally getting to this point because previously, QLC was so difficult to manage that your filesystem had to be aware that it was writing to QLC flash to use it effectively. There are a few filesystems designed for direct flash management like yaffs[0], but this isn't quite as efficient as a SSD's dedicated processor and software stack. [0]: https://yaffs.net/ https://yaffs.net/