[Btrfs-devel] Compression?

[mike]

On 6/30/07, Josef Bacik <jwhiter at redhat.com> wrote:
> In my NSHO I think encryption/compression at the FS level is overkill.  You
> start having to worry about all sorts of other things, extra room on the disk to
> describe this stuff, extra CPU to process it all, designing the different data
> structures around these features rather than solving the actual problems we face
> with filesystems, ie scalability and performance issues.  For compression we
> have stackable filesystems so you can pick and choose who is compressed without
> having to compress everybody, or even compress everybody if you want.  For
> encryption you have two solutions already that are FS agnostic, eCryptFS and
> dm-crypt, depending on which you require.  Again I personally feel that filling
> up the filesystem with features such as encryption and compression is going to
> result in comprimises in important features, such as data integrity, performance
> and scalability.  Thank you,

keeping something such as encryption as close to the filesystem core
seems key to me.

dm-crypt, ecryptfs, all sorts of things are just loopback, file
containers, encrypted file contents/filenames/some metadata but still
guessable file structures.

i don't see the issue, just disable it if you do not require it. but
with the growing amount of regulations (HIPPA for example) there seems
to be an open market for integrated, transparent encryption so that no
unencrypted data never hits a disk platter. the only complicated thing
i can think of how to deal with keys/key management.

compression doesn't seem like it will have a lot of payoff to me.
there are plenty of products that do compression already, lots of
content is already compressed, etc. it may be technically easier to
implement, but that is probably the reason why not many filesystems
offer true native encryption support.

as far as integrity goes, i would expect that integrity stays the
same, all actions would occur on the mounted (unencrypted) filesystem
or unencrypt it during the specific actions where needed.

scalability... this goes back to "just don't use it then" - but it
would be a welcome option. for example, i wouldn't turn on
compression. most things i store are pre-compressed and i don't need
the overhead. disks are pretty cheap.

also, depending on how it is written i believe it can tap into
encryption acceleration products/add-in cards. modern processors seem
to handle encryption decent as well. i run drivecrypt on windows
machines and they claim it adds maybe 3% of overhead... i really don't
see any noticable performance loss either.