Write-stream IDs

Posted Apr 10, 2015 12:54 UTC (Fri) by dwmw2 (subscriber, #2063)
In reply to: Write-stream IDs by butlerm
Parent article: Write-stream IDs

The whole "pretend to be a disk" thing is a layering problem. We really want the file system to be able to see the underlying flash and make use of it directly.

So you end up with precisely this kind of layering violation in order to pass additional information down to the "disk" to try to let it do its job better.

The last major layering violation like this was TRIM, which allows us to tell the disk that we no longer care about the contents of certain sectors. Look how well that worked... is it still disabled by default in most file systems because of media corruption and horrid performance? Is there a version of the SATA spec yet that actually allows it to be a tagged command and queue up with other reads/writes?

Write-stream IDs: layering violations

Posted Apr 12, 2015 3:30 UTC (Sun) by giraffedata (guest, #1954) [Link]

Such things are not actually layering violations because of the way they are defined. A command that says, "deallocate this block" is a layering violation. A command that declares, "this block does not back any file" is a layering violation. But a command that says, "Fill this block with zeroes" or even "make this block have unpredictable contents" is not, even if we understand that the device will respond to that information by deallocating the block.

Likewise, declaring that you're going to overwrite two blocks at about the same time in the future does not violate layering. Telling an SSD to put the two blocks in the same erase block would.

What this is instead is messy layering, a form of excessive complexity. That's almost as bad.