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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to