* UBIFS performance
@ 2008-11-26 10:07 Brijesh Singh
2008-11-26 11:49 ` Adrian Hunter
0 siblings, 1 reply; 4+ messages in thread
From: Brijesh Singh @ 2008-11-26 10:07 UTC (permalink / raw)
To: linux-mtd
Hi,
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?
Thanks and Regards,
Brijesh
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: UBIFS performance
2008-11-26 10:07 UBIFS performance Brijesh Singh
@ 2008-11-26 11:49 ` Adrian Hunter
2008-11-27 3:31 ` Amit Kumar Sharma
0 siblings, 1 reply; 4+ messages in thread
From: Adrian Hunter @ 2008-11-26 11:49 UTC (permalink / raw)
To: Brijesh Singh; +Cc: linux-mtd
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: UBIFS performance
2008-11-26 11:49 ` Adrian Hunter
@ 2008-11-27 3:31 ` Amit Kumar Sharma
2008-11-27 7:49 ` Adrian Hunter
0 siblings, 1 reply; 4+ messages in thread
From: Amit Kumar Sharma @ 2008-11-27 3:31 UTC (permalink / raw)
To: Adrian Hunter, Brijesh Singh; +Cc: linux-mtd
Hi Adrian
Really good information for us, In my understanding random
read/write performance can not be greater then sequential ,
Am I right because I have seen in LFS on SSD sequential and
random performance are same , Please correct me if I am
missing any scenario.we will measure performance using perf.
Thanks
Amit
----- Original Message -----
From: "Adrian Hunter" <ext-adrian.hunter@nokia.com>
To: "Brijesh Singh" <brij.singh@samsung.com>
Cc: <linux-mtd@lists.infradead.org>
Sent: Wednesday, November 26, 2008 5:19 PM
Subject: Re: UBIFS performance
> 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.
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: UBIFS performance
2008-11-27 3:31 ` Amit Kumar Sharma
@ 2008-11-27 7:49 ` Adrian Hunter
0 siblings, 0 replies; 4+ messages in thread
From: Adrian Hunter @ 2008-11-27 7:49 UTC (permalink / raw)
To: Amit Kumar Sharma; +Cc: linux-mtd, Brijesh Singh
Amit Kumar Sharma wrote:
> Really good information for us, In my understanding random
> read/write performance can not be greater then sequential ,
> Am I right because I have seen in LFS on SSD sequential and
> random performance are same , Please correct me if I am
> missing any scenario.we will measure performance using perf.
Without knowing the internals of the SSD, it is impossible to
predict anything about sequential vs random performance. It
depends entirely on the design of the SSD.
However, excluding the effect of hardware, file systems are
likely to give better performance for sequential I/O than
random I/O.
> ----- Original Message -----
> From: "Adrian Hunter" <ext-adrian.hunter@nokia.com>
> To: "Brijesh Singh" <brij.singh@samsung.com>
> Cc: <linux-mtd@lists.infradead.org>
> Sent: Wednesday, November 26, 2008 5:19 PM
> Subject: Re: UBIFS performance
>
>
>> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-11-27 7:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-11-26 10:07 UBIFS performance Brijesh Singh
2008-11-26 11:49 ` Adrian Hunter
2008-11-27 3:31 ` Amit Kumar Sharma
2008-11-27 7:49 ` Adrian Hunter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox