UBIFS performance measurements

UBIFS performance measurements

[Leo Barnes]

Hello!

I have a few questions regarding sequential write speeds in UBIFS and
how to measure them.

1. If I want to measure sequential (and later on, random) write speed
in UBIFS, should I do the writes using the O_SYNC flag or just do a
fsync after writing? I worry that using the O_SYNC flag will reduce
the write performance since the file system is meant to be used
asynchronously and I want my measurements to be as close as possible
to how the file system is meant to be used.

2. If I do not use O_SYNC, will using fflush and fsync guarantee that
all written data has been written to flash when they return?

3. If I do not use fflush before fsync, I assume, after reading the
FAQ, that I am not guaranteed that all data has been written. Is this
correct?

4. Does the commandline sync command do the same thing as fflush/fsync?

5. Does sync/fsync force garbage collection? In other words, if I have
deleted lots of files from an UBIFS volume, will I be ensured that
their corresponding eraseblocks will actually be freed if I do a sync?

Any other tips regarding how to perform valid write performance
measurements on UBIFS would be welcome.

Best regards,
//Leo

Re: UBIFS performance measurements

[Artem Bityutskiy]

Hi,

On Thu, 2010-06-17 at 10:42 +0200, Leo Barnes wrote:
> I have a few questions regarding sequential write speeds in UBIFS and
> how to measure them.

Measurements are always tricky... :-) But I'm happy to help answering
specific UBIFS questions, of course.

> 1. If I want to measure sequential (and later on, random) write speed
> in UBIFS, should I do the writes using the O_SYNC flag or just do a
> fsync after writing? I worry that using the O_SYNC flag will reduce
> the write performance since the file system is meant to be used
> asynchronously and I want my measurements to be as close as possible
> to how the file system is meant to be used.

With O_SYNC you will get a guarantee that when your 'write()' call
returns, every single byte of your buffer will be on the flash media.
Yes, this is slow. This is un-optimal, because UBIFS will waste a lot of
space flushing the write-buffer every time.

With out O_SYNC you will do your writes to the page cache, then when you
call fsync(), UBIFS will flush this all, but this should be faster
because UBIFS will waste less space and pack data nodes nicely to the
write buffer.

It makes sense to measure both. But yes, write all / fsync is closer to
real life.

> 2. If I do not use O_SYNC, will using fflush and fsync guarantee that
> all written data has been written to flash when they return?

Yes.

> 3. If I do not use fflush before fsync, I assume, after reading the
> FAQ, that I am not guaranteed that all data has been written. Is this
> correct?

Yes, because some amount of data is cached in usre-space somewhere in
libc, and was not even sent to the kernel yet. fsync() will just call
the syscall without flushing that buffered data.

> 4. Does the commandline sync command do the same thing as fflush/fsync?

It syncs all (kernel) dirty pages, for all files. fsync synchronize only
one file.

> 5. Does sync/fsync force garbage collection?

No, they do minimum stuff to make sure all data is on the media and
would not lost if you had a power cut just after sync/fsync is done.

>  In other words, if I have
> deleted lots of files from an UBIFS volume, will I be ensured that
> their corresponding eraseblocks will actually be freed if I do a sync?

No. You are guaranteed that these files will never come back only. But
on physical flash level, corresponding PEBs will not necessarily be
erased.

> Any other tips regarding how to perform valid write performance
> measurements on UBIFS would be welcome.

Well, not from me, although I am of course interested to see people
using UBIFS :-) FS testing is always tricky, and the best testing is
using the FS with real-life applications. E.g., if you have some apps
with back-end data-bases, or you have some apps doing intensive I/O,
installing removing packages, etc.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)