On Tuesday 09 December 2008, Miguel Figueiredo Mascarenhas Sousa Filipe wrote: > Hi there, > > On Tue, Dec 9, 2008 at 2:59 PM, Lee Trager <[EMAIL PROTECTED]> 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.
You could just use an additional partition for /boot that has compression an encryption disabled... > > 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. > > > > Would this be a reasonable thing to implement? Any suggestions before I > > start doing this? > > Things like compression or encription should be used at the "volume" level. That was what I said some time ago when I asked why encryption support for btrfs is planned. On a volume level you can use dm-crypt and the fs can ignore that part completely. The answer was that different users on a home partition could use their own encryption key. That sounds like volume level is out of bet. ;) > So.. if a user wants a specific set of files or dirs ..they should > create a mount-point/volume like: > > private_vol > bigarchives_vol > > and set those volumes as compressed or encripted volumes > > Regarding usability, the best would be for the sub-volume creation > tool to optionally allow passing encription/compression arguments. > > > and then: > should mount those volumes somewhere like: ~/Confidential or ~/Archives. > > Basically, do it at the directory level (which in btrfs is at the > sub-volume level). > File-level granularity is totally unmanageable in the long term. > > Kind regards, -- Regards, Chris _______________________________________________ Btrfs-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/btrfs-devel
