If multiple compression schemes are implemented how should the user go
about choosing which one they want? Should it be done at kernel time? Or
with the userland tools on a per file basis(maybe zlib is the default
but a user could say I want this directory to be bzip)?
On Mon, Dec 15, 2008 at 11:14:01PM +0100, devzero@web.de
wrote:> fantastic feature!
>
> i`m curious: can btrfs support more than one compression scheme at the same
time, i.e. is compression "pluggable" ?
If you look at compression.c, compression.h, and ctree.h you can clearly
see that support for multiple compression scheme was in mind. Implmented
a new one shouldn''t be to hard but you probably want to make the
current
system a little bit more pluggable and move all the zlib stuff into
zlib.c.>
> lzo compression coming to my mind, as this is giving real-time compession
and may even speed up disk access.
>
> compression ratio isn`t too bad, but speed is awesome and doesn`t need as
much cpu as gzip.
>
In some tests I''ve run zlib is actually faster then nocompression
because of the lesser amount of data that has to transfer to and from
the disk. It would be instresting to see how bzip works with this
to.> experimental lzo compression in zfs-fuse showed that it could compress
tarred kernel-source with 2.99x compressratio (where gzip gave 3.41x), so maybe
lzo is a better algorithm for realtime filesystem compression...
>
> regards
> roland
>
>
>
> From: Chris Mason <chris.mason <at> oracle.com>
> Subject: Re: Compressed Filesystem
> Newsgroups: gmane.comp.file-systems.btrfs
> Date: 2008-10-29 20:08:42 GMT (6 weeks, 5 days, 1 hour and 53 minutes ago)
>
> On Wed, 2008-10-29 at 12:14 -0600, Anthony Roberts wrote:
> > Hi, I have a few questions about this:
> >
> > > Compression is optional and off by default (mount -o compress to
enable
> > > it). When enabled, every file is compressed.
> >
> > Do you know what the CPU load is like with this enabled?
>
> Now that I''ve finally pushed the code out, you can try it ;) One
part
> of the implementation I need to revisit is the place in the code where I
> do compression means that most of the time the single threaded pdflush
> is the one compressing.
>
> This doesn''t spread the load very well across the cpus. It can be
> fixed, but I wanted to get the code out there.
>
> The decompression does spread across cpus, and I''ve gotten about
800MB/s
> doing decompress and checksumming on a zero filled compressed file. At
> the time, the disk was reading 14MB/s.
>
> >
> > Do you know whether data can be compressed at a sufficient rate to
still
> > saturate the disk on recent-ish AMD/Intel CPUs?
>
> My recentish intel cpu can compress and checksum at about 120MB/s.
> >
> > If no, is the effective pre-compression I/O rate still comparable to
the
> > disk without compression?
> >
>
> It depends on your disks...
>
> > I''m pretty sure that won''t even matter in many cases
(eg you''re seeking
> > too much to care, or you''re on a VM with lots of cores but
congested
> > disks, or you''re dealing with media files that it
doesn''t bother
> > compressing, etc), but I''m curious what sort of overhead this
adds. :)
> >
> > Mostly it seems like a good tradeoff, it trades plentiful cores for
scarce
> > disk resources.
>
> This varies quite a bit from workload to workload, in some places
it''ll
> make a big difference, but many workloads are seek bound and not
> bandwidth bound.
>
> -chris
>
>
> ____________________________________________________________________
> Psssst! Schon vom neuen WEB.DE MultiMessenger geh?rt?
> Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
>
> --
> 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
--
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