public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Roland" <devzero@web.de>
To: "Lee Trager" <lt73@cs.drexel.edu>,
	"Chris Mason" <chris.mason@oracle.com>
Cc: <linux-btrfs@vger.kernel.org>
Subject: Re: Compressed Filesystem
Date: Tue, 16 Dec 2008 20:45:13 +0100	[thread overview]
Message-ID: <099201c95fb6$d0633920$0301a8c0@bui.materna.com> (raw)
In-Reply-To: 20081216162500.GA9685@tux64-01

>I agree that adding more options will add more complexity but it seems
> the same amount of work in kernel space will have to be done

regarding lzo compression itself - it`s already there(since july 2007).
the in-kernel lzo is equivalent to minilzo. 
(http://www.oberhumer.com/opensource/lzo/)

regards
roland


----- Original Message ----- 
From: "Lee Trager" <lt73@cs.drexel.edu>
To: "Chris Mason" <chris.mason@oracle.com>
Cc: "Lee Trager" <lt73@cs.drexel.edu>; <devzero@web.de>; 
<linux-btrfs@vger.kernel.org>
Sent: Tuesday, December 16, 2008 5:25 PM
Subject: Re: Compressed Filesystem


>I agree that adding more options will add more complexity but it seems
> the same amount of work in kernel space will have to be done. If we
> support mutiple compression schemes somewhere the compression scheme
> used will have to be stored so we know what to use in the future. If we
> store it on the super block the user will have to choose when they
> format at which point they may not see the need to use compression. Or
> they may choose one compression scheme and later want to change to
> something else. It doesn't make sence to have to reformat your drive
> just to change compression scheme. This leaves us with storing what the
> compression scheme is on each inode.  We currently store if compression
> is used on a per inode basis so storing the type wouldn't be a huge
> leap.
>
> Lee
> On Tue, Dec 16, 2008 at 10:26:10AM -0500, Chris Mason wrote:
>> On Tue, 2008-12-16 at 10:20 -0500, Lee Trager wrote:
>> > While I agree that the command you send should be possible it wasn't
>> > exactly what I was thinking. Currently I am working on a way for the
>> > user to individually set which files/directories they want compressed 
>> > or
>> > not. What I was saying is that assuming you are in a mounted btrfs
>> > directory you could do something like
>> >
>> > chattr -R +c zlib dir1 Compress dir1 and all its contents with zlib
>> > chattr -R +c bzip dir2 Compress dir2 and all its contents with bzip
>> > chattr +c lzo file1 Compress fil1 with lzo
>> > chattr -c file2 Uncompress file2
>> > chattr +c none dir3 Uncompress dir3 but leave contents as is
>> >
>> > If the user did something like
>> > mount -o compress,cscheme=zlib /dev/xyz /mntpoint
>> > and then
>> > chattr +c /mntpoint/dir
>> > /mntpoint/dir would default to zlib as would anything else written to
>> > the disk.
>> >
>>
>> This is one of those places where more options isn't always better.
>> Every option adds complexity to the filesystem and the testing matrix.
>>
>> I'd much rather have just one compression scheme per FS.  If people need
>> a specific compression scheme for a specific file, they can just
>> compress it in userland.
>>
>> -chris
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html 


  reply	other threads:[~2008-12-16 19:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-15 23:19 Compressed Filesystem devzero
2008-12-16 15:20 ` Lee Trager
2008-12-16 15:26   ` Chris Mason
2008-12-16 16:25     ` Lee Trager
2008-12-16 19:45       ` Roland [this message]
2008-12-18 15:55         ` Chris Mason
  -- strict thread matches above, loose matches on Subject: below --
2008-12-16 18:14 devzero
2008-12-15 22:14 devzero
2008-12-15 23:07 ` Lee Trager
2008-10-27 14:54 Lee Trager
2008-10-28 15:47 ` Chris Mason
2008-10-28 16:33   ` Lee Trager
2008-10-28 17:38     ` Chris Mason
2008-10-28 17:40       ` Zach Brown
2008-10-28 17:46         ` Chris Mason
     [not found]       ` <53696.2001:470:e828:1::2:2.1225304096.squirrel@avalon.arbitraryconstant.com>
2008-10-29 20:08         ` Chris Mason
2008-11-04  0:08           ` Chris Samuel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='099201c95fb6$d0633920$0301a8c0@bui.materna.com' \
    --to=devzero@web.de \
    --cc=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lt73@cs.drexel.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox