Re: sd performance tests, bonnie++ with different filesystems.
On Sat, Jun 26, 2010 at 11:19, Gennady Kupava wrote: >>> - flash dying > >>no big problem on replacable uSD > > yeah, it's much better to replace sd once in year for example but have +30% > r/w speed during year. Please, don't look at uSD cards as flash devices. They have wear leveling mechanism to comply with that, so you don't really have to care about that (except on REALLY heavy usage) -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
sd performance tests, bonnie++ with different filesystems.
Hi, > XFS is not prone to power failures anymore or it's not an issue on uSD (without big cache as normal drives)? i thought it is same to btrfs? i am using xfs on desktop for storing data like films, audio and other big and non-critical data, have no problems for 5 years. i've heard about 0 files, after power failure, which were somehow intelligently described (and seem fixed http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F ) i think this is only on writes. i took that into accout, using to for / and /usr, which are changed only on system upgrades. why do you think xfs is less proof to to power failures that others? >> - flash dying >no big problem on replacable uSD yeah, it's much better to replace sd once in year for example but have +30% r/w speed during year. >> - problem with bootloaders >if you load kernel from different partition then I don't see any problem with brtfs rootfs. yeah, I used ext2 for /boot -> uboot is happy. i even used GPT for fun, so finally my partitions numbered 1,2,3,4,... without 'extendeds' so far, i didn't notice some significant difference except it only fsck /boot for a long time. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
sd performance tests, bonnie++ with different filesystems.
Hi, list. >It's good to see someone doing tests on this, but more info is needed on what fs creation and mount options were applied by default. all fses were created with default options, you can check published script, which has mkfses line-by-line. > Of particular interest would be whether btrfs used the ssd option by default. i'll do next run with both ssd and non-ssd versions of btrfs. > and how the compress option would affect the results - does the cpu overhead of compression outweigh the reduction of bus traffic between cpu and glamo? hm, from my POV it depends now much it loads CPU, hm... need to add this on next run. Al, thanks for suggestions, next run is not priority for me, as i already choosen filesystems for my freerunner, but a bit later i'll do it, as a minimum to check your suggestions about btrfs. >Is it possible to tune these file systems to achieve better results? If someone has suggestions about other filesystems, they are welcome. Sure, it's possible, but i didn't want to spend a week studiing all kinds of options for all kind of filesystems just to repartition my sd, just wanted to choose fs intelligently :) but topic is interesting in general (we all have USB flashes not only sd in moko). >What does "% CPU" field name stands for? Is it CPU load or idle? this is standard table for bonnie++, it stands for cpu load of course. >Interesting how bad results you got for brtfs (I guess that MeeGo people also did some benchmarks, before selecting is as default fs). Maybe because rather slow cpu in freerunner? i didn't bury in detatils, to answer this question it's better try first to optimize btrfs. but all i read about btrfs were some bad details, like this http://lkml.org/lkml/2010/6/3/313 it's strange to choose something experimental, in development fs with unstable disk format for production system, also it's entirely possible that MeeGo people choose it because 'it's cool', 'it's cool for target audience', "our devs participate in btrfs development and they say ...", or something like this. also, by guess is that btrfs is more complex than others. anyway using significatly more cpu is bad for embedded, as it eats more power. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: sd performance tests, bonnie++ with different filesystems.
On Sat, Jun 26, 2010 at 09:03:00AM +, jougnz jougnz wrote: > ARM Cortex-A8 600MHz (n900) vs Samsung 2442 400MHz (openmoko) ? well brtfs benchmark shown pretty high cpu load and I think that MeeGo people develop and target also newer devices then old n900 (maybe N9, which I guess will be much faster then freerunner or n900) Also without glamo with better bus bandwidth it can be different IMHO. > Suppose that the btrfs has the following problems: > - flash dying no big problem on replacable uSD > - problem with bootloaders if you load kernel from different partition then I don't see any problem with brtfs rootfs. Regards, -- Jansa 'JaMa' Martin jabber: martin.ja...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: sd performance tests, bonnie++ with different filesystems.
> Date: Sat, 26 Jun 2010 09:45:53 +0200 > From: martin.ja...@gmail.com > To: community@lists.openmoko.org > Subject: Re: sd performance tests, bonnie++ with different filesystems. > > On Thu, Jun 24, 2010 at 03:57:30PM +0400, Gennady Kupava wrote: > > Hi, list. > > Hi Gennady, > > > my conclusion here is that good filesystems: > > ext2 and ext4 have same performance in this test. > > reiserfs is best, despite of name of it's creator. > > ext2 is good except file creation and remove. > > xfs is good except file creation and remove. > > ext3 is good _for_ file creation and remove. > > Interesting how bad results you got for brtfs (I guess that MeeGo people > also did some benchmarks, before selecting is as default fs). Maybe > because rather slow cpu in freerunner? ARM Cortex-A8 600MHz (n900) vs Samsung 2442 400MHz (openmoko) ? This is the important argument. I suppose that the freerunner developers need to write software better than other which developes for n900 :) Suppose that the btrfs has the following problems: - flash dying - problem with bootloaders > > > so, my choise of fs will be: > > /boot -> ext2 for compatibility > > /, /usr -> xfs, need fast block r/w. > > XFS is not prone to power failures anymore or it's not an issue on uSD > (without big cache as normal drives)? > > Thanks a lot for benchmark! > > Regards, > > -- > Jansa 'JaMa' Martin jabber: martin.ja...@gmail.com > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. https://signup.live.com/signup.aspx?id=60969___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: sd performance tests, bonnie++ with different filesystems.
On Thu, Jun 24, 2010 at 03:57:30PM +0400, Gennady Kupava wrote: > Hi, list. Hi Gennady, > my conclusion here is that good filesystems: > ext2 and ext4 have same performance in this test. > reiserfs is best, despite of name of it's creator. > ext2 is good except file creation and remove. > xfs is good except file creation and remove. > ext3 is good _for_ file creation and remove. Interesting how bad results you got for brtfs (I guess that MeeGo people also did some benchmarks, before selecting is as default fs). Maybe because rather slow cpu in freerunner? > so, my choise of fs will be: > /boot -> ext2 for compatibility > /, /usr -> xfs, need fast block r/w. XFS is not prone to power failures anymore or it's not an issue on uSD (without big cache as normal drives)? Thanks a lot for benchmark! Regards, -- Jansa 'JaMa' Martin jabber: martin.ja...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: sd performance tests, bonnie++ with different filesystems.
[cut] > All tests were done on .34, yesterday git (with FIFO LCM patch). Short > tests algorithm: for each fs: create fs on same mmc partition, mount > (with noatime) and run bonnie in mounted directory, then umount. I did > two runs to ensure results are sane. Great work Gennady! Just two questions. Is it possible to tune these file systems to achieve better results? What does "% CPU" field name stands for? Is it CPU load or idle? -- Patryk "LeadMan" Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: sd performance tests, bonnie++ with different filesystems.
It's good to see someone doing tests on this, but more info is needed on what fs creation and mount options were applied by default. These can have a major effect on the results. Of particular interest would be whether btrfs used the ssd option by default, and how the compress option would affect the results - does the cpu overhead of compression outweigh the reduction of bus traffic between cpu and glamo? On Thursday 24 June 2010, Gennady Kupava wrote: > Hi, list. > > Unexpectedly, seems it's time for me to repartition my sd card. > > So i decided to find which filesystem is best for current kernels, and > to share my results as this topic should be interesting to everyone who > is using sd card as storage for data. > > The participants - btrfs nilfs2 ext2 ext3 ext4 reiserfs jfs xfs. > > The old well-know test is bonnie++. > > Resulting html table, with 2 runs: > http://www.bsdmn.com/openmoko/fstest/fstestresults.html > > The test script: > http://www.bsdmn.com/openmoko/fstest/fsbench.sh > > Results are really hard to interpret, all filesystems has weak and > strong sides, but i'll try to do some summary now, for whoose who is > interested. > > 1. sequental io, this is quite rare now, so not really matter. > 1.1 sequental output per char > reiser, btrfs is non-usable in this respect. ext3 is close to unusable, > xfs is almost ok. all others same. > 1.2. sequental input per char > all almost the same - latency +-25%, expect btrfs, which is 30% slower > and have extraoridinary latencies. xfs is not good at speed too. > > 2. block io, most important thing. > 2.1 8k blocks write > here is most surprise - ext4 and ext2 are slowest. almost 50% slower > than xfs, jfs. ext3 have outstandingly bad latency. > 2.2 most important thing for fs - block read. > they all the same, except btrfs, which is much slower. > 2.3. rewrite > all almost same, expect btrfs and ext3. > > 3. random seeks. > it's seek+read or write. useful operation. only test where btrfs is > relatively good in performance. > > 4. create/delete tests > 1. Create (random) > great difference here, ext2, ext4, xfs, are bad. ext3, btrfs, reiser > 5-10 times better. > 2. delete (random) > ext2,ext3,ext4,reiser,btrfs are good, jfs and xfs 10 times slower. > > my conclusion here is that good filesystems: > ext2 and ext4 have same performance in this test. > reiserfs is best, despite of name of it's creator. > ext2 is good except file creation and remove. > xfs is good except file creation and remove. > ext3 is good _for_ file creation and remove. > > so, my choise of fs will be: > /boot -> ext2 for compatibility > /, /usr -> xfs, need fast block r/w. > /home -> reiser, need fast file create/remove, and overall balance > /var -> reiser, 'append fs', need good overall balance. > > i wanted to test nilfs2 (and use it for /var), but it didn't pass > testing - out of free space. > > All tests were done on .34, yesterday git (with FIFO LCM patch). Short > tests algorithm: for each fs: create fs on same mmc partition, mount > (with noatime) and run bonnie in mounted directory, then umount. I did > two runs to ensure results are sane. > > plain dd read speed of my sd card is 2.7Mb/s. > > Gennady. > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
sd performance tests, bonnie++ with different filesystems.
Hi, list. Unexpectedly, seems it's time for me to repartition my sd card. So i decided to find which filesystem is best for current kernels, and to share my results as this topic should be interesting to everyone who is using sd card as storage for data. The participants - btrfs nilfs2 ext2 ext3 ext4 reiserfs jfs xfs. The old well-know test is bonnie++. Resulting html table, with 2 runs: http://www.bsdmn.com/openmoko/fstest/fstestresults.html The test script: http://www.bsdmn.com/openmoko/fstest/fsbench.sh Results are really hard to interpret, all filesystems has weak and strong sides, but i'll try to do some summary now, for whoose who is interested. 1. sequental io, this is quite rare now, so not really matter. 1.1 sequental output per char reiser, btrfs is non-usable in this respect. ext3 is close to unusable, xfs is almost ok. all others same. 1.2. sequental input per char all almost the same - latency +-25%, expect btrfs, which is 30% slower and have extraoridinary latencies. xfs is not good at speed too. 2. block io, most important thing. 2.1 8k blocks write here is most surprise - ext4 and ext2 are slowest. almost 50% slower than xfs, jfs. ext3 have outstandingly bad latency. 2.2 most important thing for fs - block read. they all the same, except btrfs, which is much slower. 2.3. rewrite all almost same, expect btrfs and ext3. 3. random seeks. it's seek+read or write. useful operation. only test where btrfs is relatively good in performance. 4. create/delete tests 1. Create (random) great difference here, ext2, ext4, xfs, are bad. ext3, btrfs, reiser 5-10 times better. 2. delete (random) ext2,ext3,ext4,reiser,btrfs are good, jfs and xfs 10 times slower. my conclusion here is that good filesystems: ext2 and ext4 have same performance in this test. reiserfs is best, despite of name of it's creator. ext2 is good except file creation and remove. xfs is good except file creation and remove. ext3 is good _for_ file creation and remove. so, my choise of fs will be: /boot -> ext2 for compatibility /, /usr -> xfs, need fast block r/w. /home -> reiser, need fast file create/remove, and overall balance /var -> reiser, 'append fs', need good overall balance. i wanted to test nilfs2 (and use it for /var), but it didn't pass testing - out of free space. All tests were done on .34, yesterday git (with FIFO LCM patch). Short tests algorithm: for each fs: create fs on same mmc partition, mount (with noatime) and run bonnie in mounted directory, then umount. I did two runs to ensure results are sane. plain dd read speed of my sd card is 2.7Mb/s. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
