Hacker News Reader

Comment by seanalltogether | Hacker News Reader

Not sure if I'm asking this correctly but, all SSDs now have their own internal filesystem for managing access to blocks right? Are we getting to a point where traditional filesystems like NTFS or ext4 will simply go away? Or will they still stick around and just act as lightweight layers on top of the SSD filesystem?

View on HN

The flash translation layers in SSDs implement things equivalent to the journalling functionality in modern filesystems, but they don't really provide any hierarchical organization of data. So you'll still need a normal host-based filesystem for the foreseeable future, but filesystem design can be influenced by the assumption that it's running atop flash storage.

There are several efforts underway to provide more specialized software interfaces to SSDs. Several vendors have produced models that expose a key-value store instead of fixed-size block storage; with those drives, you can throw away RocksDB and speak directly to the drive with the same semantics (subject to limitations on supported key and value sizes).

There are a few competing standards for open-channel SSDs that move some of the FTL onto the host CPU so that the journalling overhead doesn't have to exist at multiple layers; the different solutions here vary in terms of how much complexity they move to the CPU vs. how much abstraction the SSD still provides for the sake of software portability. Most of the potential benefits this approach provides are being subsumed by extensions to the NVMe protocol that allow the host and SSD to exchange optional hints about data layouts, GC status, etc.

SK Hynix recently announced they're working on a SSD with transactional storage support, so that the host can send multiple write commands and either commit or abort the transaction as a whole.

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/

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

Is there a way for the drive to tell the fs that a block is bad? Or does the drive simply keep a bunch of blocks apart just in case?

Hard drives and SSDs both keep a pool of spare blocks so that they can remain functional after having to retire some defective blocks from use. This spare pool tends to be much larger for SSDs. Ordinary IO doesn't convey anything about whether a block had to be retired in the process, but there are SMART indicators that track this stuff.

Those flash translation layers on the SSDs are generally used to maintain QoS/and do wear leveling, block management etc.

I don't think we'll see file systems go away, but what we may see is more knowledge pushed into the file system, instead of keeping it down in the controller.

We have started to see that with the advent of LightNVM which exposes a more RAW API into the drive and the FTL is maintained in the kernel. The current "generic" implementation of the LightNVM FTL is called pblk:

https://elixir.bootlin.com/linux/latest/source/drivers/light...

Probably not putting drives in charge of the entire filesystem, but object storage would be a good way to let the drive manage itself and take care of the details of where to store everything. The SCSI commands for object storage have existed for a decade but so far haven't seen much uptake.

Those filesystems seem to handle different design requirements though. I also don't trust most vendors to properly encrypt the drives in the firmware [1], so I end up putting dm-crypt over most drives. It also doesn't account for raid setups, which are usually done at the block level. (Although I like snapraid for some use cases.)

[1] https://www.welivesecurity.com/2018/11/15/security-researche...

I think it's unlikely that manufacturers will want to turn their consumer SSD devices into a dumb flash storage and move their FTL into the open (like a API layer inside the Linux kernel). It's where their added value lies.

I think we're talking about the opposite where the SSD could take over some functionality from the OS.

Which OS? There are many, which is why they won't.

Reply on news.ycombinator.com