3 ms·
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 wil
by 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 agoRewriting data on ZFS is also a needed feature to complement RAIDZ expansion.