4 ms·

Thank you very much for this explanation - I was about to respond with "I hear it's really, really hard ..." ... and this was much more useful and interesting

• cryptonector 4y ago
  Because making such a change seems ETOOHARD, I don't expect anyone to be interested in making it in the OpenZFS community. It would take a fork, and no one will want that either. Instead I think the OpenZFS community could maybe develop an automatic and transparent feature like what you do: internally "zfs send" a dataset, and then apply any transactions that took place at the origin while doing that, then lock the origin dataset, do one more round of transaction copying to the new dataset, then atomically swap the old and new, unlock, then destroy the old. But I'm very curious what filesystems devs think of the CAS idea. It's not original, mind you. CAS is a well researched topic. I'm dead certain there's nothing wrong with a CAS design for a filesystem -- the key is to make the logical -> physical block pointer mapping fast, which is why I'd have a cache right next to every interior block, with the cache excluded from the Merkle hash tree.
  • fomine3 4y ago
    Rewriting data on ZFS is also a needed feature to complement RAIDZ expansion.
• cryptonector 4y ago
  I wonder if a company like rsync.net would fund work to make that "zfs send and swap" thing automatic and transparent. Or to fund a ZZFS. If for you the defragmentation need is critical... Not that I'm offering to do any of that work, mind you, but I am curious how much it would cost, and whether it'd be worth anyone's while.