3 ms·

I actually agree that using the block interface makes sense for storage but would have loved to have a minimal interference from the SSD. If it just exposed the

by baruch 14y ago

I actually agree that using the block interface makes sense for storage but would have loved to have a minimal interference from the SSD. If it just exposed the entire flash to address by the user and reported when a block has problems and maybe some stats about the underlying flash chips I'd be very happy. It would then enable building better things at the OS/Application side. There is quite a bit of a chicken-and-egg problem here though, all the current filesystems basically assume that the underlying media never has any faults and if it does than the media problems are static and do not develop over time. This is obviously incorrect for flash, but even for rotating media it wasn't true. Since every OS requires a fault-free media the SSD vendors are working hard to make sure they provide a semblance of such fault-free media they make it harder to provide the best possible performance or a different trade-off than what they have taken.

vy8vWJlco 14y ago
I also want lower-level access, but I would presumably not be using it for files/reliable storage. If a lossy interface is acceptable, why couldn't SSDs simply expose a faster albeit lossy block device and, if necessary, an extended SMART or custom inspection method, and let the user take responsibility for wear-leveling, ECC, etc? It would be backwards compatible with other things by virtue of presenting the standard block interface. A common ECC+wear-leveling middle layer could evolve allowing use of standard filesystems and a common codebase for all flash storage, relieving the apparent burden on SSD vendors who would love to sell fast unreliable storage rather than reliable storage. I think the chicken-egg problem is just an egg problem though, because even though I'd love lower level access to the unreliable bits, I have to expect that the market for unreliable storage is very small, not unlike the high-efficiency-but-sometimes-exploding toilet. :) If reliable storage is the primary use-case, maybe the drives just need to be smarter to keep up. I'd rather an ASIC handle ECC, etc, transparently (for the same reasons I'd rather have a dedicated GPU) than run ECC (or 3D floating point software) on my general processor. If you inevitably want reliable storage and just wind up running ECC, etc, on the CPU, the speed gains disappear and we're back in something similar to a pre-DMA world with the main processor doing something that could be done in parallel by a dedicated chip. If the hard drive is the right place for the offload, I'd rather the economic pressures remain for the SSD vendors to optimize inside that black box, behind the standard reliable interface. That said, again, I too would love finer-grain control.
- baruch 14y ago
  I can see a mix where some parts are done by hardware, ECC comes in there. Other things should be done in software (FTL, error recovery, RAID). The block interface itself is actually matching the flash, you read/write/erase in blocks, they may not be 512 bytes but rather 4k/8k/256k whatever works for the underlying hardware.
Sami_Lehtinen 14y ago
Don't you remember MFM and RLL with CHS addressing? Disk controller wasn't mapping bad blocks out, it was the file system.
- baruch 14y ago
  Indeed, but life then was different, the CPU was weaker and there was a good intention with pushing everything to the disk. The intention is still good but it is now possible to do things better in a different way.

by baruch 14y ago

vy8vWJlco 14y ago

I also want lower-level access, but I would presumably not be using it for files/reliable storage. If a lossy interface is acceptable, why couldn't SSDs simply expose a faster albeit lossy block device and, if necessary, an extended SMART or custom inspection method, and let the user take responsibility for wear-leveling, ECC, etc? It would be backwards compatible with other things by virtue of presenting the standard block interface. A common ECC+wear-leveling middle layer could evolve allowing use of standard filesystems and a common codebase for all flash storage, relieving the apparent burden on SSD vendors who would love to sell fast unreliable storage rather than reliable storage. I think the chicken-egg problem is just an egg problem though, because even though I'd love lower level access to the unreliable bits, I have to expect that the market for unreliable storage is very small, not unlike the high-efficiency-but-sometimes-exploding toilet. :) If reliable storage is the primary use-case, maybe the drives just need to be smarter to keep up. I'd rather an ASIC handle ECC, etc, transparently (for the same reasons I'd rather have a dedicated GPU) than run ECC (or 3D floating point software) on my general processor. If you inevitably want reliable storage and just wind up running ECC, etc, on the CPU, the speed gains disappear and we're back in something similar to a pre-DMA world with the main processor doing something that could be done in parallel by a dedicated chip. If the hard drive is the right place for the offload, I'd rather the economic pressures remain for the SSD vendors to optimize inside that black box, behind the standard reliable interface. That said, again, I too would love finer-grain control.

baruch 14y ago
I can see a mix where some parts are done by hardware, ECC comes in there. Other things should be done in software (FTL, error recovery, RAID). The block interface itself is actually matching the flash, you read/write/erase in blocks, they may not be 512 bytes but rather 4k/8k/256k whatever works for the underlying hardware.

Sami_Lehtinen 14y ago

Don't you remember MFM and RLL with CHS addressing? Disk controller wasn't mapping bad blocks out, it was the file system.

baruch 14y ago
Indeed, but life then was different, the CPU was weaker and there was a good intention with pushing everything to the disk. The intention is still good but it is now possible to do things better in a different way.