5 ms·
For anyone wondering "why", this linked article in the source gives some background, https://blog.westerndigital.com/storage-architectures-zettabyte-age/ https:
by keeperofdakeys 7y ago
For anyone wondering "why", this linked article in the source gives some background, https://blog.westerndigital.com/storage-architectures-zettabyte-age/ https://blog.westerndigital.com/storage-architectures-zettab...
So instead of SMR harddrives and SSDs doing extra work to hide their deficiencies, they're pushing this up into the filesystem. In return you get slightly more storage and slightly faster IO. Perhaps not useful on a desktop, but very useful when dealing with thousands of storage devices in a data centre.
In terms of how it would be exposed to users, this feels very well fitted with object storage. Unlike file-based storage, each object can only be read or replaced. So any partial write relies on the program to read the whole object, then write the updated object.
- Rapzid 7y agoIt's not every day a new disk storage implementation detail makes it this far up the storage stack.
- mbjorling 7y agoTrue - the great thing is that we have been optimizing for this type of interface for the last decade. I.e., due to the benefits of making writes sequential (both for HDDs and SSDs) We, the industry, have just been missing the interface to actually perfectly align our workloads to the media that we store the data on. The zone interface bridges this gab.
- bonzini 7y agoIt also fits well log-structured and copy-on-write filesystems.
- paol 7y agoYes! That was my first thought. The way SMR and SSDs work actually aligns pretty well with log structured filesystems. In this case, the firmware translation layer is only getting in the way.
- mbjorling 7y agoA presentation of the SSD benefits is available here: https://m.youtube.com/watch?v=9yVWb3rbces https://m.youtube.com/watch?v=9yVWb3rbces (Full disclosure - my talk at OCP 2019)