From: Li Zefan <lizf@cn.fujitsu.com>
To: Maciej Marcin Piechotka <uzytkownik2@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Inefficient storing of ISO images with compress=lzo
Date: Tue, 20 Sep 2011 10:19:20 +0800 [thread overview]
Message-ID: <4E77F828.5030401@cn.fujitsu.com> (raw)
In-Reply-To: <1316473579.31049.2.camel@picard>
07:06, Maciej Marcin Piechotka wrote:
> On Mon, 2011-09-19 at 10:53 +0800, Li Zefan wrote:
>> Maciej Marcin Piechotka wrote:
>>> I've noticed that:
>>>
>>> - with x86-64 Fedora 15 DVD install images:
>>> - du -sh <ROOT VOLUME> was 36 GB
>>> - btrfs df | grep -i data have shown over 40 GB used
>>> - without
>>> - du -sh <ROOT VOLUME> is 34 GB
>>> - btrfs df | grep -i data have shown less then 34 GB used
>>>
>>> It seems that iso files are considered compressable while they may not be (and penalty is severe - 3x).
>>>
>>
>> With compress option specified, btrfs will try to compress the file, at most
>> 128K at one time, and if the compressed result is not smaller, the file will
>> be marked as uncompressable.
>>
>> I just tried with Fedora-14-i386-DVD.iso, and the first 896K is compressed,
>> with a compress ratio about 71.7%, and the remaining data is not compressed.
>>
>> --
>> Li Zefan
>
> Just a question from person who don't know how btrfs operates - what if
> the beginning of file is well compressable and the rest is not?
>
It's explained in the previous mail - the beginning part will be compressed,
and the rest will not.
> In any case the compression was my uneducated guess where is missing
> 4GB.
>
It probably has nothing to do with compression. You can try without compress=lzo,
and see if the issue still exists.
next prev parent reply other threads:[~2011-09-20 2:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-18 23:32 Inefficient storing of ISO images with compress=lzo Maciej Marcin Piechotka
2011-09-19 2:53 ` Li Zefan
2011-09-19 3:13 ` Li Zefan
2011-09-19 23:06 ` Maciej Marcin Piechotka
2011-09-20 2:19 ` Li Zefan [this message]
2011-09-20 14:29 ` David Sterba
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=4E77F828.5030401@cn.fujitsu.com \
--to=lizf@cn.fujitsu.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=uzytkownik2@gmail.com \
/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).