3 ms·

> No file system should be doing random writes, A typical size for a SMR zone is 256MB, and any writes that aren't appending sequentially to what's already bee

> No file system should be doing random writes, A typical size for a SMR zone is 256MB, and any writes that aren't appending sequentially to what's already been written to that zone count as "random writes" on a SMR drive. That's an absolutely massive block size to expect filesystems to work around, and I doubt there are any commonly used filesystems that can store their metadata in a SMR-friendly way.

sitkack 7y ago
Metadata belongs in persistent storage (PMEM or flash), file contents can striped onto a magnetic disk. Flash suffers from the same problem. Rewriting a file should be appending binary diffs to a log and reapply the writes against the first version into a new location on the cluster. SMR is extremely painful for anyone except those that can handle distributed storage systems. I think the only place where SMR makes sense for home users is in a DVR, or game assets where a virtual disk is streamed down from a cloud provider in a single pass, and no interior mutations.
- wtallis 7y ago
  Ok, so when you say "no file system should be doing random writes", you should make it clear that you're not trying to describe file systems that actually exist in any sort of production-ready state. I would generally agree with a statement that new filesystems should be designed to avoid random writes except to solid state media. But for users wanting to deploy a real filesystem now to commodity hardware, the recommendation has to be "avoid SMR", not "use a smarter FS and tiered storage hardware".
  - sitkack 7y ago
    Correct. SMR should be sold to tiered storage providers OR SMR drives should include a scratch flash or pmem device to hide the large write amplification of rewriting a block (ala back to tiered storage). HN is fringe, I am not making statements about people with drobos.
Dylan16807 7y ago
For many copy-on-write or log-structured filesystems it's not particularly hard to adapt them to such a block size, but I don't think it has actually been done on a major scale yet.

sitkack 7y ago

Metadata belongs in persistent storage (PMEM or flash), file contents can striped onto a magnetic disk. Flash suffers from the same problem. Rewriting a file should be appending binary diffs to a log and reapply the writes against the first version into a new location on the cluster. SMR is extremely painful for anyone except those that can handle distributed storage systems. I think the only place where SMR makes sense for home users is in a DVR, or game assets where a virtual disk is streamed down from a cloud provider in a single pass, and no interior mutations.

wtallis 7y ago
Ok, so when you say "no file system should be doing random writes", you should make it clear that you're not trying to describe file systems that actually exist in any sort of production-ready state. I would generally agree with a statement that new filesystems should be designed to avoid random writes except to solid state media. But for users wanting to deploy a real filesystem now to commodity hardware, the recommendation has to be "avoid SMR", not "use a smarter FS and tiered storage hardware".
- sitkack 7y ago
  Correct. SMR should be sold to tiered storage providers OR SMR drives should include a scratch flash or pmem device to hide the large write amplification of rewriting a block (ala back to tiered storage). HN is fringe, I am not making statements about people with drobos.

Dylan16807 7y ago

For many copy-on-write or log-structured filesystems it's not particularly hard to adapt them to such a block size, but I don't think it has actually been done on a major scale yet.