From: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>
To: Richard Weinberger <richard.weinberger@gmail.com>,
Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: Linux mtd <linux-mtd@lists.infradead.org>
Subject: Re: JFFS2 vs. UBIFS compression
Date: Mon, 24 Aug 2015 08:33:00 +0800 [thread overview]
Message-ID: <55DA663C.6080707@cn.fujitsu.com> (raw)
In-Reply-To: <CAFLxGvw6dOG1Opwp8i9pW6o65HbYF-vu6iFpQmYOH_EMJqB2aA@mail.gmail.com>
On 08/24/2015 02:03 AM, Richard Weinberger wrote:
> On Fri, Aug 21, 2015 at 11:00 AM, Ricard Wanderlof
> <ricard.wanderlof@axis.com> wrote:
>>
>> I came across something odd that I wasn't really expecting the other day.
>>
>> On a JFFS2 file system, we have a file that is 12.25 MB in size. When
>> written to an 8 MB partition, df reports that it occupies 5.9 MB. Writing
>> a second copy of the file fails because the file system is full. Fair
>> enough.
>>
>> On a similar UBIFS system (however in this case with a volume size of 32
>> MB), the same file is reported by df to have occupied 7.9 MB. Writing
>> multiple copies of the same file confirms that we can fit slightly more
>> than 4 copies of the same file on the file system (32 MB / 7.9 MB yields
>> 4.05), so 7.9 MB seems about right.
>>
>> Now I fully understand that getting df to report valid figures for
>> compressed file systems is guesswork at best, but don't JFFS2 and UBIFS
>> utilize the same compression algorithms? Consequently, the space used by
>> especially large files (where the overhead is small) should be essentially
>> the same for both file systems? If anything, one would expect that UBIFS,
>> being newer, would better at compression than JFFS2.
>>
>> So what are we seeing here, is UBIFS more conservative in reporting disk
>> usage, or is JFFS2 really better than UBIFS at file compression?
>
> Both support zlib and lzo. Did you setup UBIFS and JFFS2 with the same
> compression method?
Yes, and ubifs is using lzo by default while JFFS2 is using zlib by
default. lzo is faster than zlib in compression and decompression.
But zlib provides a better ratio than lzo. So as Richard suggested,
it's better to make sure you are using the same compressor in your
testing. Thanx for your interesting.
BTW, there is an option named as --favor-percent in mkfs.ubifs. Maybe
that could help to do a balance between these compressors for you.
Yang
> Also keep in meed to run "sync" before using "df" on UBIFS.
> Otherwise it will not write down to flash and report the uncompressed size.
>
> HTH
>
prev parent reply other threads:[~2015-08-24 0:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-21 9:00 JFFS2 vs. UBIFS compression Ricard Wanderlof
2015-08-23 18:03 ` Richard Weinberger
2015-08-24 0:33 ` Dongsheng Yang [this message]
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=55DA663C.6080707@cn.fujitsu.com \
--to=yangds.fnst@cn.fujitsu.com \
--cc=linux-mtd@lists.infradead.org \
--cc=ricard.wanderlof@axis.com \
--cc=richard.weinberger@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.