[Yaffs] Yaffs2 vs. UBIFS: pros and cons?

[Russell]

Hello everyone,

Question #1: I was told that UBIFS is better than Yaffs2, is that true? What are pros and cons?
Question #2: It was said that Android 2.1 cannot use Yaffs2, is that true? If so, why?

BR
Russell

[Bob Dunlop]

Hi,

Well I can answer one question.

Post by Russell
Question #2: It was said that Android 2.1 cannot use Yaffs2, is that true? If so, why?

Android requires/uses xattr and the YAFFS file system doesn't support xattr.

A quick Google of "Android XATTR" shows that several people are working on
it. I looked into xattr on yaffs2 a few months back and didn't think any of
the solutions were mature enough for my purposes at that time.

[Eugene Surovegin]

Post by Russell
Question #2: It was said that Android 2.1 cannot use Yaffs2, is that true? If so, why?

Android Eclair can use yaffs2 mounts just fine, in fact, yaffs2 is the
default fs for raw NANDs in Android (Nexus One uses yaffs2).

[Charles Manning]

Post by Russell
Hello everyone,
Question #1: I was told that UBIFS is better than Yaffs2, is that true?
What are pros and cons?

What does "better" mean?

Each is better than the other in some ways.
Each is faster than the other at some things.

The major difference is in the write policy. UBIFS caches far more and defers
writes more than yaffs does. This makes UBIFS writes appear to be faster much
of the time, but then UBIFS syncs are slower. Unless you get a clean sync in
UBIFS you will lose data.

For example under UBIFS:

#cp foo bar
#
kill power a second or so after cp completes.

will give you a zero length file for bar even if bar held a valid file before
the foo. YAFFS on the other hand will give you a complete file as closing a
file will commit everything to flash.

It is important to not take historic benchmarks and comparisons too seriously
as both UBIFS and YAFFS continue to develop. YAFFS has sped up significantly
in the last 6 months (approx 50% read speed up and 40% write speed up,
depending on hardware etc). Last I looked, UBIFS also has limitations like
lack of memory-mapped file writing and limitations like that might have gone
away.

Post by Russell
Question #2: It was said that Android 2.1 cannot
use Yaffs2, is that true? If so, why?

I had not heard that. I have a reasonably close relationship with the Android
kernel team and they have not said a word to me about that. I'd better ask
them.


-- Charles

[Russell]

Charles, Bob, Laurie, Eugene,

Thank you all for your information, it is great help for me!

BR
Russell

-----Original Message-----
From: yaffs-***@lists.aleph1.co.uk [mailto:yaffs-***@lists.aleph1.co.uk] On Behalf Of Charles Manning
Sent: Friday, May 28, 2010 5:32 AM
To: ***@lists.aleph1.co.uk
Subject: Re: [Yaffs] Yaffs2 vs. UBIFS: pros and cons?

Post by Russell
Hello everyone,
Question #1: I was told that UBIFS is better than Yaffs2, is that true?
What are pros and cons?

What does "better" mean?

Each is better than the other in some ways.
Each is faster than the other at some things.

The major difference is in the write policy. UBIFS caches far more and defers
writes more than yaffs does. This makes UBIFS writes appear to be faster much
of the time, but then UBIFS syncs are slower. Unless you get a clean sync in
UBIFS you will lose data.

For example under UBIFS:

#cp foo bar
#
kill power a second or so after cp completes.

will give you a zero length file for bar even if bar held a valid file before
the foo. YAFFS on the other hand will give you a complete file as closing a
file will commit everything to flash.

It is important to not take historic benchmarks and comparisons too seriously
as both UBIFS and YAFFS continue to develop. YAFFS has sped up significantly
in the last 6 months (approx 50% read speed up and 40% write speed up,
depending on hardware etc). Last I looked, UBIFS also has limitations like
lack of memory-mapped file writing and limitations like that might have gone
away.

Post by Russell
Question #2: It was said that Android 2.1 cannot
use Yaffs2, is that true? If so, why?

I had not heard that. I have a reasonably close relationship with the Android
kernel team and they have not said a word to me about that. I'd better ask
them.


-- Charles

[Nick Bane]

Post by Russell
Hello everyone,
Question #1: I was told that UBIFS is better than Yaffs2, is that true? What are pros and cons?
Question #2: It was said that Android 2.1 cannot use Yaffs2, is that true? If so, why?
BR
Russell
_______________________________________________
yaffs mailing list
http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs

I recently ported ubifs to a balloon3 development system and wish to report
some findings.

The kernel is 2.6.34 with nand write verify disabled due to subpage write
problems exposed by ubifs, using yaffs checkout 2009-09-10 and using
default ubifs lzo compression.

1) The first test was decompressing a 41MB tgz unconfigured rootfs from a
pen drive into a nand partition. This was done using tar -xzf
../sda1/embdebianrootstrap.tgz from the empty mounted nand partition.

yaffs2: 5:20
ubifs: 1:38

2) dpkg --configure -a after chrooting into the new rootfs partition

yaffs2: 6:25
ubifs: 5:01

3) booting from bootldr prompt into the newly created rootfs cleanly
unmounted. This including kernel reading-decomprerssing-initialisation time
of about 5 secs.

yaffs2: 0:28
ubifs: 0:23

4) rebooting into cleanly unmounted rootfs

yaffs2: 0:28
ubifs: 0:23

5) rebooting into power yanked rootfs (no writes)

yaffs2: 0:36
ubifs: 0:24

6) single write to small file then reboot via power yank

yaffs2: 0:36
ubifs: 0:24

Under ubifs, df reported 69MB of filesystem space used representing 126MB
of du reported data. The increased boot/read speed might be accounted for
by the fewer nand reads (software ecc) needed due to data compression.

This leaves the tgz decompression figures to be explained as the difference
is remarkable. Copying the tgz to /dev/null took 44 seconds of reading from
a usb 1 mounted memory stick reducing the residual timings to
yaffs2: 4:36 vs ubifs: 0:54.

These figures take no account of newer yaffs2 speed improvements, no
account of the degraded power security of cached writes and no account of
reliability issues surrounding not verifying nand writes. Verifying nand
writes is ok under ubifs but the header offsets must be page (not sub-page)
aligned until sub-page verifies are fixed in mtd. Using page aligned
headers which requires that userland ubifs utils must have knowledge of the
underlying nand architecture - ugh.

My impression of running our applications on ubifs is that the write speed
and boot speed (especially without a clean unmount) is faster but without
the numbers to back it up this is only an impression. Installing packages
using dpkg (which makes many writes/moves) also seems much faster. Overall
reliability is far too early to judge.

If someone can tell me how to do a git checkout without using long
unmemorable nubers I could redo this with a more modern yaffs2.

Nick Bane

[Nick Bane]

Update with current yaffs added below

Post by Nick Bane

Post by Russell
Hello everyone,
Question #1: I was told that UBIFS is better than Yaffs2, is that
true? What are pros and cons?
Question #2: It was said that Android 2.1 cannot use Yaffs2, is that true? If so, why?
BR
Russell
_______________________________________________
yaffs mailing list
http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs

I recently ported ubifs to a balloon3 development system and wish to
report some findings.
The kernel is 2.6.34 with nand write verify disabled due to subpage
write problems exposed by ubifs, using yaffs checkout 2009-09-10 and
using default ubifs lzo compression.
1) The first test was decompressing a 41MB tgz unconfigured rootfs from
a pen drive into a nand partition. This was done using tar -xzf
../sda1/embdebianrootstrap.tgz from the empty mounted nand partition.
yaffs2: 5:20
ubifs: 1:38

I retried with the latest yaffs2 checkout. Decompression was 5:58.

Post by Nick Bane
2) dpkg --configure -a after chrooting into the new rootfs partition
yaffs2: 6:25
ubifs: 5:01

configure took 6:03

Nick

Post by Nick Bane
3) booting from bootldr prompt into the newly created rootfs cleanly
unmounted. This including kernel reading-decomprerssing-initialisation
time of about 5 secs.
yaffs2: 0:28
ubifs: 0:23
4) rebooting into cleanly unmounted rootfs
yaffs2: 0:28
ubifs: 0:23
5) rebooting into power yanked rootfs (no writes)
yaffs2: 0:36
ubifs: 0:24
6) single write to small file then reboot via power yank
yaffs2: 0:36
ubifs: 0:24
Under ubifs, df reported 69MB of filesystem space used representing
126MB of du reported data. The increased boot/read speed might be
accounted for by the fewer nand reads (software ecc) needed due to data
compression.
This leaves the tgz decompression figures to be explained as the
difference is remarkable. Copying the tgz to /dev/null took 44 seconds
of reading from a usb 1 mounted memory stick reducing the residual
timings to
yaffs2: 4:36 vs ubifs: 0:54.
These figures take no account of newer yaffs2 speed improvements, no
account of the degraded power security of cached writes and no account
of reliability issues surrounding not verifying nand writes. Verifying
nand writes is ok under ubifs but the header offsets must be page (not
sub-page) aligned until sub-page verifies are fixed in mtd. Using page
aligned headers which requires that userland ubifs utils must have
knowledge of the underlying nand architecture - ugh.
My impression of running our applications on ubifs is that the write
speed and boot speed (especially without a clean unmount) is faster but
without the numbers to back it up this is only an impression. Installing
packages using dpkg (which makes many writes/moves) also seems much
faster. Overall reliability is far too early to judge.
If someone can tell me how to do a git checkout without using long
unmemorable nubers I could redo this with a more modern yaffs2.
Nick Bane
_______________________________________________
yaffs mailing list
http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs

[Andre Renaud]

Post by Nick Bane

Post by Russell
Hello everyone,
Question #1: I was told that UBIFS is better than Yaffs2, is that
true? What are pros and cons?
Question #2: It was said that Android 2.1 cannot use Yaffs2, is that true? If so, why?

<snip>

Post by Nick Bane
These figures take no account of newer yaffs2 speed improvements, no
account of the degraded power security of cached writes and no account
of reliability issues surrounding not verifying nand writes. Verifying
nand writes is ok under ubifs but the header offsets must be page (not
sub-page) aligned until sub-page verifies are fixed in mtd. Using page
aligned headers which requires that userland ubifs utils must have
knowledge of the underlying nand architecture - ugh.
My impression of running our applications on ubifs is that the write
speed and boot speed (especially without a clean unmount) is faster but
without the numbers to back it up this is only an impression. Installing
packages using dpkg (which makes many writes/moves) also seems much
faster. Overall reliability is far too early to judge.
If someone can tell me how to do a git checkout without using long
unmemorable nubers I could redo this with a more modern yaffs2.

I am curious as to whether these numbers, which seem to imply UBIFS is
drastically faster than YAFFS (tar decompress 3x faster, dpkg 20% faster
etc...) might be to do with using compression. The CPUs a lot of people
are using now are pretty high end, and while NAND speed has improved, it
is probably still quicker to compress data and thus write less of it.

Has anyone ever looked at using LZO or similar compression within YAFFS
to reduce the amount of data written?

Regards,
Andre

[Charles Manning]

Post by Andre Renaud

Post by Nick Bane

Post by Russell
Hello everyone,
Question #1: I was told that UBIFS is better than Yaffs2, is that
true? What are pros and cons?
Question #2: It was said that Android 2.1 cannot use Yaffs2, is that true? If so, why?

<snip>

Post by Nick Bane
These figures take no account of newer yaffs2 speed improvements, no
account of the degraded power security of cached writes and no account
of reliability issues surrounding not verifying nand writes. Verifying
nand writes is ok under ubifs but the header offsets must be page (not
sub-page) aligned until sub-page verifies are fixed in mtd. Using page
aligned headers which requires that userland ubifs utils must have
knowledge of the underlying nand architecture - ugh.
My impression of running our applications on ubifs is that the write
speed and boot speed (especially without a clean unmount) is faster but
without the numbers to back it up this is only an impression. Installing
packages using dpkg (which makes many writes/moves) also seems much
faster. Overall reliability is far too early to judge.
If someone can tell me how to do a git checkout without using long
unmemorable nubers I could redo this with a more modern yaffs2.

I am curious as to whether these numbers, which seem to imply UBIFS is
drastically faster than YAFFS (tar decompress 3x faster, dpkg 20% faster
etc...) might be to do with using compression. The CPUs a lot of people
are using now are pretty high end, and while NAND speed has improved, it
is probably still quicker to compress data and thus write less of it.

I think the main reason UBIFS will do an untar faster is that it does
not write directly into flash.
UBIFS writes everything into RAM and then writes to flash in background.

If you do an untar with UBIFS and then kill power before the
background writing has happened you'll end up with a bunch of empty
files. You are not really measuring the write speed, just the caching
speed.

A far more realistic measurement is:

#untar ....; sync

Post by Andre Renaud
Has anyone ever looked at using LZO or similar compression within YAFFS
to reduce the amount of data written?

This is something we talked about in very early YAFFS days. There are
some pros and cons.

Pros: Less writes, more stored.
Cons: Really bad for any form of overwrite (one of the main reasons
JFFS2 does not support memory mapped writing).

You can get some of the Pros by storing compressed files (eg. vai loop
mounting).

-- Charles

[Andre Renaud]

Post by Charles Manning

Post by Andre Renaud
Has anyone ever looked at using LZO or similar compression within YAFFS
to reduce the amount of data written?

This is something we talked about in very early YAFFS days. There are
some pros and cons.
Pros: Less writes, more stored.
Cons: Really bad for any form of overwrite (one of the main reasons
JFFS2 does not support memory mapped writing).
You can get some of the Pros by storing compressed files (eg. vai loop
mounting).

Hi Charles,
Do you know if this means that UBIFS doesn't support mmap'd IO?

Regards,
Andre

[Charles Manning]

Post by Andre Renaud

Post by Charles Manning

Post by Andre Renaud
Has anyone ever looked at using LZO or similar compression within YAFFS
to reduce the amount of data written?

This is something we talked about in very early YAFFS days. There are
some pros and cons.
Pros: Less writes, more stored.
Cons: Really bad for any form of overwrite (one of the main reasons
JFFS2 does not support memory mapped writing).
You can get some of the Pros by storing compressed files (eg. vai loop
mounting).

Hi Charles,
Do you know if this means that UBIFS doesn't support mmap'd IO?

Last time I checked it did not. Whether that is still the case I do not know.

-- Charles

[Artem Bityutskiy]

Post by Charles Manning

Post by Andre Renaud

Post by Charles Manning

Post by Andre Renaud
Has anyone ever looked at using LZO or similar compression within YAFFS
to reduce the amount of data written?

This is something we talked about in very early YAFFS days. There are
some pros and cons.
Pros: Less writes, more stored.
Cons: Really bad for any form of overwrite (one of the main reasons
JFFS2 does not support memory mapped writing).
You can get some of the Pros by storing compressed files (eg. vai loop
mounting).

Hi Charles,
Do you know if this means that UBIFS doesn't support mmap'd IO?

Last time I checked it did not. Whether that is still the case I do not know.

JFFS2 has problems only with MAP_SHARED.

JFFS2 does not support MAP_SHARED simply because it is fully synchronous
FS and every write goes synchronously to the media. So with shared mmaps,
every byte you change would have to be written to the media synchronously,
which makes little sense because it would be dead slow.

I do not know how YAFFS supports MAP_SHARED without implementing write-back.
What is the trick?

UBIFS, as any standard FS, supports write-back, so it has no problems with
shared mmaps(): you change your bytes, they are changed in the page-cache,
the page is marked as dirty, and later on write-back takes care of flushing
it. Just like in any standard FS like ext3.

Thus, no, UBIFS has no problems with shared mmaps.

Vs zero files Charles mentioned - sure asynchronous FS has its own costs
- the applications have to have less bugs be aware of how to use fsync()
and the like. This is the price for very fast writes. But hey, these are
standard things which existed for ages.

But no one cancelled the -o sync mount option which will make UBIFS fully
synchronous, but of course slower.

I wrote quite a lot of docs about write-back:
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writeback
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_wb_knobs

Also, it is possible to implement several UBIFS hacks like ext4 implemented
recently to lessen possible impacts for buggy apps: sync on close and sync
on move:
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_sync_exceptions