5 ms·
My understanding is that for ZFS, things like this would require a mythical feature called "block pointer rewrite", the same feature required to implement out-o
by rcthompson 6y ago
My understanding is that for ZFS, things like this would require a mythical feature called "block pointer rewrite", the same feature required to implement out-of-band deduplication.
- rincebrain 6y agoYou are correct - ZFS hardcodes the assumption that data's location on disk will never change once written very deeply, and offline dedup/data migrating of any sort would require that. (It would also be a performance nightmare - you'd have a permanent indirection table you'd need to use for _everything_, and if you've ever seen how ZFS dedup performs with its indirection table not on dedicated SSDs, you can understand why this is terrible.)
- tpetry 6y agoThe block could still be rewritten from the view of zfs as long as it does not update the last-written timestamp (does zfs have this?). I was just describing how it would look like from the birds eye.
- rdc12 6y agoDirectly no, but if you moved the data to a new dataset, with a command that preserves the timestamp that would work (rsync -a or zfs send/recv), which could be run from a cronjob. Compression settings are set at a per dataset level, so applying this to only some files in a dataset isn't practical.