On Thu, Sep 15, 2016 at 10:24:02AM -0400, Austin S. Hemmelgarn wrote: > On 2016-09-15 10:06, Anand Jain wrote: > >>How does this handle cloning of extents? Can extents be cloned across > >>subvolume boundaries when one of the subvolumes is encrypted? > > > > Yes only if both the subvol keys match. > OK, that makes sense. > > > >>Can they > >>be cloned within an encrypted subvolume? > > > > Yes. That's things as usual. > Glad to see that that still works. Most people I know who do batch > deduplication do so within subvolumes but not across them, so that still > working with encrypted subvolumes is a good thing.
I do continual filesystem-wide deduplication across subvolumes, but I don't think this is a problem. There are already a number of conditions when IOC_FILE_EXTENT_SAME might fail and deduplicators must tolerate those failures. Cross-subvol dedup has to loop over all duplicate block references (including those in other subvols) until all references to one of the blocks are eliminated. So dedup should still work by sheer brute force, banging extents together until they stick, but it would be noisy and slower if it was not aware of encrypted subvols. If there's a way to look at the subvolume properties and figure out whether the extents are clonable (e.g. equal key IDs == clonable) then it should be easy to avoid submitting FILE_EXTENT_SAME extent pairs belonging to incompatibly encrypted subvols. They can also be stored in separate DDT entries (e.g. by extending the hash field) so that blocks from incompatibly encrypted subvols won't have matching extended hashes.
signature.asc
Description: Digital signature
