Filesystem shootout

[DaDaDaniel]

Thank you very much!

 

[chaotix]

Excellent work Sir!

Thanks.

How about a PND that can execute the test battery (with card-ID information) and save the output to a text file that the user can upload to an online database linked to the FAQ? It would enable us to have this level of detail by file system by card for everyone who is willing to participate and put their card's info up.

I have to admit, I like the idea. But it's not really trivial.

• First the tool would have to check the erase block size. I don't know if this can be done automatically, but maybe the user could try to interpret the flashbench output. Checking if the partition is aligned correctly shouldn't be too hard once the erase block size is known.
  
• The test ist destructive as it needs to reformat a partition. And I really don't want to be responsible for people losing their data. But maybe a big enough warning could prevent that.
  
• Testing takes a lot of time. Even the shorter test with just one mount option took 10 hours. Maybe the number of bonnie runs can be reduced from 1 + 5 to 1 + 3. But this would still take nearly 7 hours. And you shouldn't use the Pandora during this time as to not influence the benchmarking. I don't know how many people would be willing to do this.
  
• At the moment Bonnie++ is run inside a Debian chroot which is about 250MB in size. But I guess it could be compiled to run directly on the Angstrom although I haven't tried that yet.
  

So I think the technical problems can all be solved with a bit of work. But would people be willing to run this test if it a) erases at least one partition and b ) takes so long?

 

[Grench]

So I think the technical problems can all be solved with a bit of work. But would people be willing to run this test if it a) erases at least one partition and b ) takes so long?

I would - but I'm weird that way. My largest concern would be trying to replicate your methodology - which sounds rather involved. Even slight differences in method on this would result in apples and oranges.


Maybe port Bonnie++ and give a document around the methodology used in your tests to start? Then we can have a couple adventurous people run the test on their cards to start to see what the variance really is.


Up to you if you're interested enough to move it that direction. I may have to play more with EXT4 on my 128GB cards though.

 

[chaotix]

I would - but I'm weird that way. My largest concern would be trying to replicate your methodology - which sounds rather involved. Even slight differences in method on this would result in apples and oranges.

It seems it sounds more complicated than it is. It's rather straigt forward. Bonnie does all important work. I just repeated the runs a couple of times and averaged the values.

Maybe port Bonnie++ and give a document around the methodology used in your tests to start? Then we can have a couple adventurous people run the test on their cards to start to see what the variance really is.

As you wish I put something up here: http://lxtek.de/pand...nchmark/bonnie/


There you can download a bonnie++ executable and a script to automate the test runs. But as I stated earlier: This can and will erase all data on a partition!

 

[Link]

So it's always best to unmount the SD cards before ejecting?


Ooops, I haven't been doing that.

 

[relliker]

Is the dramatic jump in the diff field on the last couple of block sizes an indication of something more significant or is it always like that on the smallest block sizes?

 

[chaotix]

So it's always best to unmount the SD cards before ejecting?

Definately yes. Even in Windows you should "Safely remove hardware" (or whatever it's called). Although I think something similiar to the "sync" option is in use there to minimize the risk.

Is the dramatic jump in the diff field on the last couple of block sizes an indication of something more significant or is it always like that on the smallest block sizes?

Are you talking about the example data on the flashbench utility page? 8KB is a common page size. But I don't think this has any relevance to us. More information is in the flashbench README file.

 

[Grench]

Would it be possible to include EXFAT while you're there? I'd like to be able to read/write my camera's cards in my Pandora. Camera only likes EXFAT on the big SDXC cards.

Although there are implentations for Linux, I don't think it is possible to include exFat in the stock firmware for legal reasons.


From https://en.wikipedia.org/wiki/ExFAT

Microsoft has not released the official exFAT file system specification, and a restrictive license from Microsoft is required in order to make and distribute exFAT implementations. Microsoft also asserts patents on exFAT which make it impossible to re-implement its functionality in a compatible way without violating a large percentage of them.[11] This renders the implementation, distribution, and use of exFAT as a part of free or open-source operating systems or of commercial software, for which the vendors could not obtain a license from Microsoft, not only technically difficult, but legally impossible in countries that recognize United States software patents.

Maybe in can be included in the codec pack. But this is more a legal than a technical issue.

Or maybe not as onerous as that.


"This project aims to provide a full-featured exFAT file system implementation for GNU/Linux other Unix-like systems as a FUSE module."


http://code.google.com/p/exfat/

 

[sepulep]

is there a way to change the (default) automount options? (so e.g. removing dirsync)

 

[chaotix]

Yes, you can change the default options. You have to edit the shell script at /etc/udev/scripts/mount.sh.


Around line 39 the filesystems get mounted:

if ! $MOUNT -t auto -o dirsync,noatime,umask=0 $DEVNAME "/media/$name" && ! $MOUNT -t auto -o dirsync,noatime $DEVNAME "/media/$name"

Just remove both occurances of "dirsync" or make any other changes you think necessary (e.g. noatime to relatime).

(The mount command is called twice as the first try fails on filesystems with permission handling (ext2/3/4) due to the "umask=0" option.)



And while you are at it you might also want to modify the entry that gets written to .hal-mtab. I don't really know if this is necessary but it's neater nonetheless

echo "$DEVNAME $uid 0	 $fstype dirsync,noatime,umask=0 /media/$name" >> /media/.hal-mtab

If you mess the script up somehow the automount feature will probably cease to function. (Although a fresh copy of the script should fix that.)


And if do remove the "dirsync" option please remember to unmount your cards before ejecting them. (You should do so anyway but now you really, really should do it (If unmounting does not work for any reason, the right method is to see which program has files open on the card, stop it and try to unmount again. If this does not work and you really want to get the card out without a reboot you can type "sync" in the terminal. Once this command is finished you can eject the card with minimal risk of filesystem corruption.))

 

[sepulep]

Quote MultiQuote Report

thanks! luckily I am already paranoid about unmounting! :rolleyes:

 

[chaotix]

I got a new card (SanDisk Mobile Ultra 16GB microSDHC Class 10) and repeated the testing procedures. The new card was the slowest on block output, but the fastest in every other test.


Interestingly the card was also not affected by partition alignment performance issues. I still aligned the partition to the erase block size as I don't want to have more block wear than necessary.


If you are interested in more detailed results, I updated the benchmark page at http://lxtek.de/pand...stem-benchmark/

 

[Grench]

I got a new card (SanDisk Mobile Ultra 16GB microSDHC Class 10) and repeated the testing procedures. The new card was the slowest on block output, but the fastest in every other test.


Interestingly the card was also not affected by partition alignment performance issues. I still aligned the partition to the erase block size as I don't want to have more block wear than necessary.


If you are interested in more detailed results, I updated the benchmark page at http://lxtek.de/pand...stem-benchmark/

I don't have time to figure out Debian in a Chroot and only have the 256MB Pandora, so I'm not sure if I'm going to be able to duplicate your methodology to test my cards. Is there a difference between the 256MB/512MB Pandoras in running Debian that way? Does it change the SD card benchmark results?


Would you be willing to run a card or two through your test set up if we provided the card to you and the return postage to send back when testing completes? I.e. you don't get to keep the cards, but you do get to add them to your test results without having to buy them.


If I can be guaranteed of getting them back, I'd be willing to loan out one at a time:


Lexar 128GB SDXC 133X class 10


Lexar 128GB SDXC 400X class 10 UHS-I


Patriot LX 32GB SDHC class 10


Kingston 32GB SDHC class 4


Very cool.

 

[chaotix]

I don't have time to figure out Debian in a Chroot and only have the 256MB Pandora, so I'm not sure if I'm going to be able to duplicate your methodology to test my cards. Is there a difference between the 256MB/512MB Pandoras in running Debian that way? Does it change the SD card benchmark results?

You don't have to run it in a Debian chroot anymore. I put up instructions on http://lxtek.de/pand...nchmark/bonnie/ on how to reproduce the test with minimal fuss. (It might be helpful to uncomment the BLOCKS=2000000 line as I had some trouble on the last test with mkfs.vfat not detecting the right filesystem size.) So getting it to run should not take more than three minutes, but testing itself takes several hours.


I don't know if there is a difference between a 256MB and a 512MB Pandora regarding the results, but there really should not be. The file size for bonnie is big enough so that there should not be any effective caching on the block in-/output tests. Maybe the file creation read tests are affected. But those are the least interesting results of them all anyway as they are already pretty fast anyway.

Would you be willing to run a card or two through your test set up if we provided the card to you and the return postage to send back when testing completes? I.e. you don't get to keep the cards, but you do get to add them to your test results without having to buy them.

Maybe you can give it a shot with the instructions above. Just ask if you run into any trouble. I don't think shipping the cards around the world (I live in Germany) is the most effective way (and probably pretty expensive if you want to insure the letter/parcel).

If I can be guaranteed of getting them back, I'd be willing to loan out one at a time:


Lexar 128GB SDXC 133X class 10


Lexar 128GB SDXC 400X class 10 UHS-I


Patriot LX 32GB SDHC class 10


Kingston 32GB SDHC class 4

If you ssh into your Pandora and run the tests from there you can just send me the output of the script via copy & paste. If you give me the permission to publish the results I can put them on my benchmark page. I would like to see some more results.

 

[lomaxx]

I was trying to follow your instructions to find out the erase block size of my Transcend 4GB (class6). First I tried to run "flashbench" on the Pandora but it didn't work. I had various strange results when running it. Getting no output at all was the "best" result after i compiled it on the Pandora with the cdevtools-pnd.


So I used an USB-cardreader and compiled and ran flashbench on my GentooPC. There it worked, but i was not able to see a difference in the diff-times that pointed to the erase block size (like the readme-file describes to happen with some cards). So after that I wondered if I would be able to find the EBS of my card somewhere on the net and found a internet-site that mentions that you can simply find out the EBS by running

cat /sys/block/mmcblk0/device/preferred_erase_size

For my card this shows a value of "4194304" on the Pandora. Sidenote: In the same directory the "erase_size" shows a value of "512". This is the same for two different cards (Panasonic 4GB and Transcend 8GB). This all seems to be a bit strange to me. But maybe it is correct and can be used for correctly formatting these cards?

 

[klapse]

My "platinum" 64GB class 10 also has 4194304 and 512 fwiw