On Wed, Jul 17, 2019 at 08:12:25PM -0600, Andreas Dilger wrote: > It would appear from my reading of the patch that every file that is > encrypted will have the xattr saved until pass2? If the filesystem is very > large (eg. billions of files), this will consume a large amount of memory. > > Does it make sense to compare compression xattrs during pass1, > and only track the set of different > encryption context/type/master key > sets that exist in the filesystem? Since these will typically be common > among large numbers of files, the memory will be largely reduced, > maybe one or two ints per inode (either an inode+ID pair for sparse > inodes, or just an ID for dense range of similarly-encrypted inodes with a > start+count for the whole range. > > Cheers, Andreas > That's correct. I wanted to propose something simpler first to see what people thought, but yes if this is really a concern, what we should do is assign a u32 id to each new encryption policy that is seen, and store just that id per inode. To do that we need a proper map data structure for the policy => ID mapping, which as usual is nontrivial to do in C. lib/ext2fs/rbtree.h could do, though. There's also lib/ext2fs/hashmap.c, but it doesn't implement resizing. - Eric
