Re: Selective Compression/Encryption

[jim owens <jowens@hp.com>]

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 have been working on changing the xattr code with the first
step getting it functioning properly when selinux is enabled
so we can see just how costly btrfs xattrs are in actual use.

jim