[Btrfs-devel] Compression?

[Josef Bacik]

On Fri, Jun 29, 2007 at 11:26:43PM -0700, mike wrote:
> On 6/29/07, Chris Mason <chris.mason at oracle.com> wrote:
> >It would be a disk format change right now, but we've still got a number
> >of those pending.  I'm definitely interested in compression as a
> >feature, but I haven't quite worked out the best way to do it yet in my
> >head.
> 
> i'd vote on encryption before compression. transparent encryption
> would be a huge seller and a lot harder to accomplish than
> compression. lots of data is already compressed; compression won't be
> a benefit to 100% of the data, but encryption would. not to mention
> adding additional line items to the brtfs feature set that set it
> apart...
>

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,

Josef