On Thu, 2008-12-11 at 17:03 -0500, Lee Trager wrote: > On Tue, Dec 09, 2008 at 03:22:29PM -0500, jim owens wrote: > > Joshua J. Berry wrote: > >> On Tuesday 09 December 2008 08:35:16 Chris Mason wrote: > >>> On Tue, 2008-12-09 at 09:59 -0500, Lee Trager wrote: > >>>> Currently compression and I assume if encryption is implemented it is > >>>> turned on or off during mount. There are however many times when a user > >>>> may want to select which files/directories they want to compress or > >>>> encrypt. This will also be helpful when implementing btrfs support in > >>>> grub for example. We can say the disk can be compressed/encrypted except > >>>> for /boot so compression/encryption doesn't have to be implemented in > >>>> grub. > >>>> > >>>> I was thinking of adding this functionality to the userspace application > >>>> btrfstune. The way I was thinking of doing this is when btrfstune +c is > >>>> applied to a directory or file the directory(and all its contents) or > >>>> file will always be compressed reguardless of how the filesystem is > >>>> mounted. The opposite would happen when btrfstune -c is used. > >>> This was my plan, but btrfstune probably isn't the best program to do it > >>> (the ext2 tune program is mostly aimed at the super block level things). > >>> > >>> I think it would be better to make a setattr style program to call the > >>> ioctls. There is already a per file compression flag, and the code > >>> should already be checking it. > >> > >> Is there some reason this can't be done with the existing extended > >> attribute facilities? > >> > >> It seems like xattrs would be preferable to some btrfs-specific > >> tunable, as programs like rsync or backup tools would be able to > >> preserve (and restore) these bits with no extra work required. > > > > I had the same thought... that many btrfs per-file tunables would > > be better implemented in xattrs (I've read christoph's earlier > > objections and hope to get around those issues). > I agree that implementing it in the xattr would be best but what > userspace tools should be used to control it? lsattr/chattr or our own? > lsattr/chattr does seem to do what we want for compression but it really > has nothing for encryption. Should we also support attribute(a), no > modification(i), etc support in xattrs?
Just to clarify, I'm fine with xattrs as a user interface to set the per-inode flags. The flag for this should be stored in the inode though, and not as a btrfs xattr. There is already a flag field in the inode for this use (see NODATASUM and NODATACOW) -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
