public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Adrian Hunter <ext-adrian.hunter@nokia.com>
To: Brijesh Singh <brij.singh@samsung.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBIFS performance
Date: Wed, 26 Nov 2008 13:49:43 +0200	[thread overview]
Message-ID: <492D37D7.3010908@nokia.com> (raw)
In-Reply-To: <B76220C07A204128A4B86AE742992E46@sisodomain.com>

Brijesh Singh wrote:
>   I am testing UBIFS and JFFS2 performance on OneNand with iozone utility. 
> Interestingly, random read / write performance are slightly better than 
> sequential read / write.
> These results are consistent across multiple versions. And consistent with 
> all different record length sizes.
> 
> Correct me if I am wrong, but shouldn't sequential read/write fair better 
> than random read/write? Is this expected behavior? If yes,why?

For log-structured file systems on flash memory, there should be little
difference between sequential and random access.

That is true for UBIFS, although sequential might be slightly faster,
because it is slightly more likely to find index nodes already cached.

We recently introduced a facility called bulk-read that offers improved
sequential read speed.  It has lower overhead and benefits from OneNAND's
read-while-load operation.

We are thinking about something for writing in bigger chunks that would
benefit from OneNAND's write-while-program operation, but that will be good
for either random or sequential writes.

With regard to iozone, you need to be aware that it hides one of JFFS2's
weaknesses which is how long it takes to open a file.  Unlike UBIFS and
other file systems which just read the inode, JFFS2 has to do lots of work
putting all the file fragments together.  The bigger the file, the longer
it takes to open.  If you compare how long it takes to open a file and
read it, our experience is that UBIFS is faster than JFFS2.  Whereas
if you ignore the open time, JFFS2 is faster that UBIFS.

In mtd-utils there is a simple performance test program called perf
which includes the open time in calculations.  It is in the
tests/fs-tests/simple directory.

Also, if you want to exclude the effects of caching you may want to use
the -e and -U options for iozone.

  reply	other threads:[~2008-11-26 11:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-26 10:07 UBIFS performance Brijesh Singh
2008-11-26 11:49 ` Adrian Hunter [this message]
2008-11-27  3:31   ` Amit Kumar Sharma
2008-11-27  7:49     ` Adrian Hunter

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=492D37D7.3010908@nokia.com \
    --to=ext-adrian.hunter@nokia.com \
    --cc=brij.singh@samsung.com \
    --cc=linux-mtd@lists.infradead.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