Re: worse than expected compression ratios with -o compress

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 21, 2010 at 03:04:56PM -0500, Gregory Maxwell wrote:
> On Thu, Jan 21, 2010 at 1:16 PM, Jim Faulkner <jfaulkne@xxxxxxxxxxx> wrote:
> >
> > On Wed, 20 Jan 2010, Chris Mason wrote:
> >
> >> Please let me know if this improves your ratios
> >
> > It most certainly does!  It also greatly reduced the time required to copy
> > the data to my (not very fast) disk.  All my testing was done on 2.6.32.4.
> > The line numbers in your patch were a little off for 2.6.32.4, but I did
> > manage to apply it cleanly.  Here's the results of my testing:
> [snip]
> > I'd be very happy to see the -o compress-force option in the mainline kernel
> > someday!
> 
> 
> Sweet. But I think a force mount option is an unreasonably blunt tool.
> 
> I think two things would be nice:
> 
> (1) Fix the compression decision, I think this example suggests that
> something is broken. (I'd noticed poorer than expected compression on
> my laptop, but I'd chalked it up to the 64k blocks… now I'm not so
> confident)

The current code assumes that files have consistent data in them.  This
is very true for the average data set, but it'll be horribly wrong for
something like a database file.

> 
> (2) An IOCTL for compression control.  Userspace knows best, some
> files ought to have a different compression policy.

Yes, we'll get #2 added.

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux