4 ms·
This is huge. It's been obvious for a long time that the standard block-device abstraction isn't a great fit for SSDs. This development finally gives us a bette
by jasonhansel 7y ago
This is huge. It's been obvious for a long time that the standard block-device abstraction isn't a great fit for SSDs. This development finally gives us a better abstraction that will immensely improve performance of a wide variety of applications (possibly even SQL databases).
- BubRoss 7y agoWhy isn't a block device a good fit for an SSD?
- wtallis 7y agoNAND flash has two inherent sizes: pages and erase blocks. NAND flash pages are several times larger than the 4kB virtual memory pages that your OS prefers to deal with, and erase blocks are a few orders of magnitude larger than that. There's a lot of complexity involved in making it possible to do 512-byte or 4kB IO to NAND flash.
- BubRoss 7y agoBlock sizes can often be set to at least 65KB, does this not help the problem?
- wtallis 7y agoIt helps a bit, but keep in mind that just because your filesystem is doing most of its allocation in 64kB chunks, doesn't mean it is issuing only 64kB IOs to the drive itself.
- sliken 7y agoAdditionally it doesn't mean that your 64KB chunks aligned to your current partition are also aligned with the 64KB boundary of the underlying block device.
- Dylan16807 7y agoIt's the erase blocks that cause the real problems. If a page is 8KB or 16KB then raw writes would hit the IOPS cap before the bandwidth cap, but that wouldn't be a major source of issues. With erase blocks at a megabyte or larger, they introduce enormously complex remapping and garbage collection requirements. You can't do a whole lot about those problems with a block device API.