From: Li Zefan <lizf@cn.fujitsu.com>
To: Mitch Harder <mitch.harder@sabayonlinux.org>
Cc: Chris Mason <chris.mason@oracle.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 0/5] btrfs: Add lzo compression support
Date: Tue, 16 Nov 2010 08:57:19 +0800 [thread overview]
Message-ID: <4CE1D6EF.4070205@cn.fujitsu.com> (raw)
In-Reply-To: <AANLkTi=pRg5eFz+KS7+2k94FraofwYJitY74TVdbCOzs@mail.gmail.com>
Mitch Harder wrote:
> On Mon, Oct 25, 2010 at 9:34 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
>> Chris Mason wrote:
>>> On Mon, Oct 25, 2010 at 03:11:22PM +0800, Li Zefan wrote:
>>>> Lzo is a much faster compression algorithm than gzib, so would allow
>>>> more users to enable transparent compression, and some users can
>>>> choose from compression ratio and compression speed.
>>> This is also much smaller than I expected, really nice. It looks like
>>> older kernels won't properly deal (nicely give EIO) with lzo compressed
>>> files?
>>>
>>> We can add compatbits to deal with that if it is the case.
>>>
>> I forgot compatibility issue with older kernels..
>>
>> Though I didn't test older kernels, I don't think they can deal with lzo
>> compressed files properly, at least not for inlined extents, in which
>> case I think btrfs will just show compressed data to the users.
>>
>> So yes, an incompat flag is needed.
>
> I've been testing this set of patches on a 2.6.36 kernel with the
> latest btrfs-unstable patches, and I wanted to provide my positive
> feedback.
>
> The lzo compression patches worked as expected, and I did not
> encounter any stability problems in my testing (which mainly consisted
> of decompressing a root partition archive and doing some compiling
> chores in a chroot environment on that drive).
>
> I did some crude benchmarking on decompressing an archived root
> partition to an empty btrfs drive, and my results were similar to the
> results posted by Li Zefan in the original post. The lzo compression
> did not compress quite as well as zlib, but was much faster.
>
> I did some test mounting of a lzo-compressed partition with an older
> non-lzo-patched kernel, and as expected, the contents of the files
> were garbled. But I did not encounter kernel oops or other issues
> when trying to read the garbled files.
>
> I also wanted to confirm that my other zlib-compressed partitions did
> not encounter any issues when bouncing back and forth between a
> lzo-patched kernel and older kernels. As expected, I did not see any
> issues in the partitions that had only been mounted with zlib
> compression.
>
> You'll want an incompat flag as indicated in previous posts, but I
> look forward to seeing lzo compression in the future.
>
Thanks for testing!
I had been occupied by other things, so have been silent on this.
Actually I've added the incompat flag, but haven't done userspace
programs.
I'm setting up a git tree, and will send out a pull request to
Chris this week. (probabaly)
And I think I can add your Tested-by in the whole patchset? Except
for the ioctl change, which I guess you didn't test.
We really need more review and test for btrfs patches, so what
you've done is really appreciatated. :)
--
Li Zefan
next prev parent reply other threads:[~2010-11-16 0:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-25 7:11 [PATCH 0/5] btrfs: Add lzo compression support Li Zefan
2010-10-25 7:11 ` [PATCH 1/5] btrfs: Fix bugs in zlib workspace Li Zefan
2010-10-25 7:12 ` [PATCH 2/5] btrfs: Allow to add new compression algorithm Li Zefan
2010-10-25 7:12 ` [PATCH 3/5] btrfs: Add lzo compression support Li Zefan
2010-10-25 7:12 ` [PATCH 4/5] btrfs: Allow to specify compress method when defrag Li Zefan
2010-10-25 7:13 ` [PATCH 5/5] btrfs: Extract duplicate decompress code Li Zefan
2010-10-26 2:13 ` [PATCH 0/5] btrfs: Add lzo compression support Chris Mason
2010-10-26 2:34 ` Li Zefan
2010-11-15 18:55 ` Mitch Harder
2010-11-16 0:57 ` Li Zefan [this message]
2010-11-16 18:51 ` Mitch Harder
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=4CE1D6EF.4070205@cn.fujitsu.com \
--to=lizf@cn.fujitsu.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=mitch.harder@sabayonlinux.org \
/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;
as well as URLs for NNTP newsgroup(s).