yashsingh1/xdaforums huggingface dataset:
[Desire Android Development] woti23:
made a more realistic test scenario

16GB sdcard (14G fat32 then 2GB test filesystems)

partitions starting at n*4096 sectors

ext4:

14.26 megabytes read (730.30 kilobytes per second)

74.54 megabytes written (3.73 megabytes per second)

xfs:

14.26 megabytes read (82.99 kilobytes per second)

74.54 megabytes written (433.66 kilobytes per second)

reiserfs:

14.26 megabytes read (486.87 kilobytes per second)

74.54 megabytes written (2.48 megabytes per second)

ext2:

14.26 megabytes read (64.92 kilobytes per second)

74.54 megabytes written (339.22 kilobytes per second)

btrfs:

14.26 megabytes read (1.43 megabytes per second)

74.54 megabytes written (7.45 megabytes per second)

ext3:

14.26 megabytes read (77.28 kilobytes per second)

74.54 megabytes written (403.83 kilobytes per second)

fat32:

14.26 megabytes read (84.43 kilobytes per second)

74.54 megabytes written (441.18 kilobytes per second)

nilfs2:*

14.26 megabytes read (521.64 kilobytes per second)

74.54 megabytes written (2.66 megabytes per second)

* protection_period 30 / min_clean_segments 0% / max_clean_segments 90%

1273 created (63 per second)

Creation alone: 1000 files (1000 per second)

Mixed with transactions: 273 files (13 per second)

239 read (11 per second)

261 appended (13 per second)

1273 deleted (63 per second)

Deletion alone: 1046 files (1046 per second)

Mixed with transactions: 227 files (11 per second)

The base number of files is 1000

Transactions: 500

Files range between 8.85 kilobytes and 101.34 kilobytes in size

Working directory:

/media/4aca8e1f-36bd-4826-bc1c-919e59e804a5 (weight=1)

100 subdirectories will be used

Block sizes are: read=4.00 kilobytes, write=4.00 kilobytes
[Desire Android Development] NeoPhyTe.x360:
interesting btrfs, and nilfs2?
[Desire Android Development] melethron:
i doubt that faster write than read is realistic. Did you swap those lines?

Also did you sync? And what sheduler?

And did you make several runs. on short tests i made get HIGLY variable results since the controller may interfere.
[Desire Android Development] woti23:
i didn't swap and was irridated too, but the postmark test in the link from

Originally Posted by th3

http://www.spinics.net/lists/linux-nilfs/msg00560.html

has lower read than write too

also the internal sdd disk has

i did (exept for nilfs2) format with gparted, and let the gnome choose the mount options, so i did no optimizing at all

just the defaults

scheduler cfq, readahead 128

i was unsure about the dissapointing values from nilsfs2, but whilest doing another test with another card kernel crashed again.

can't remember when i had the last crash with a linux ;-)
[Desire Android Development] woti23:
think it maybe come into place that this postmark programm copy/writes/erases

a lot of very small files (between about 9k and 100k, and 1000 of them), which would take longer than writing to a few bigger files, not?

i'll try tommorow with

a) another cardreader / card

b) with individual options when mounting

c) with files random from 8k to 30MB

d) with more and less then 1000 files

i don't know what the command time meassures? used cpu time or time from starting command to end of process?

also don't know what postmark uses to meassure.

i expect the card i have used today would be a class 2, and had expected about the (but invers indeed) values.

i also don't think the postmark can make advantage from cache, and it seems not to get higher results when running again (files and directories are random in name and size and content and erased at end of test)
[Desire Android Development] melethron:
Ext4 should be even slower then due to the journaling. On small files nilfs2 has its REAL advantages.

One more realistic example. i copied the dalvik cache to my laptop. Then i copied it to my USB and meassured the time needed.

melethron@melethron-laptop:~/workspace/dalvik$ time (cp -ar * ~/nilfs2/trash && sync)

real 0m55.893s
user 0m0.000s
sys 0m0.440s
melethron@melethron-laptop:~/workspace/dalvik$ time (cp -ar * ~/nilfs2/trash && sync)

real 0m57.395s
user 0m0.000s
sys 0m0.504s
melethron@melethron-laptop:~/workspace/dalvik$ time (cp -ar * ~/ext4/trash && sync)

real 1m51.576s
user 0m0.012s
sys 0m0.360s
melethron@melethron-laptop:~/workspace/dalvik$ time (cp -ar * ~/ext4/trash && sync)

real 1m11.142s
user 0m0.004s
sys 0m0.608s
melethron@melethron-laptop:~/workspace/dalvik$ time (cp -ar * ~/ext4/trash && sync)

real 1m5.670s
user 0m0.012s
sys 0m0.596s
melethron@melethron-laptop:~/workspace/dalvik$ time (cp -ar * ~/nilfs2/trash && sync)

real 0m56.323s
user 0m0.004s
sys 0m0.484s

Nilfs steady ~56s.

Ext4 1 min 05s -1 min 55s

Well ext made for HDD and nilfs made for SSD.

Trying to optimize EXT4 for faster speed instead of using nilfs2 is like trying to optimize a submarine a submarine to fly instead of simply taking a plane. :D

Btw: a plane can still be optimized.
[Desire Android Development] NeoPhyTe.x360:
For when a test from mobile doing time tests copying to sdcard? :P

I could be awesome
[Desire Android Development] melethron:
^^

Well i wouldn't do bench but using this normaly on phone. But the utilitys you made wont work. Or at least the "nilfs_cleanerd" wont work ..... or do you think your phone will run script that starts with "#! /bin/bash"

nilfs_cleanerd needs to be a proper binary. Until then there is no need to make "real life" test. Without the cleaner you only get full disk space and errors-----

EDIT: Oh and apart from that there is much more stuff in the source than that like lscp. I wonder what you took to compile the utils.

I really should start to learn how to cross-compile ...
[Desire Android Development] NeoPhyTe.x360:
Yeah, I know, but today I tried to compile btrfs, it compiles well, and when make the mkfs from mobile it gives me "expecting" errors. I know bit of build and compile, so maybe somebody could help me to compile without errors, because I think it's bad compiled...
[Desire Android Development] dipje:
Isn't it a better idea to go for BTRFS with it's SSD mode turned on (and neatly aligning the partitions), than for NILFS2 whic is in a much less supported state, and more experimental?

BTRFS is already in most desktop distro's and as far as I know, will be included in the mainstream kernel when declared stable. Would safe a lot of hassle.

Is the nilfs_cleanerd really needed for normal file system operation? Isn't it just to do SSD garbage collection / trim execution which is useless since we're still talking about NAND and SD cards?

Taking a neatly aligning fat32 partition and using a loop device on it is useless, specially for the block aligning. It's nice that your FAT32 partition is aligned, but there is no way in telling that the configuration _inside_ the loop-device is aligned to the _physical_ blocks of the device. Most of the time loop devices start with a little bit of header and reserved space for MBR's / partition tables which aren't used, so the first partition starts 528 bytes into the loop device. Say goodbye to your aligning :P.

So testing _on the phone_ if btrfs or nilfs will actually matter much sounds interesting. And when aligning, please just align the _partitions_ on 1mb boundaries and you're set. Just toying with align paramters in the filesystem will do nothing if the partitions aren't properly aligned. As far as I know there is no method of determing the physical blocksize of a SD card (which is more than 4kb for sure! if the card is >= 8gb), that's why I say 'just use 1mb aligning'. It's the default in newer OS versions to be 'SSD optimized'.

Good luck, I'll lurk to see the results :P
[Desire Android Development] erpalma:
Btrfs actually does not provide a tool to fix fs errors. Also SSD option enable transparent compression wich use quite a lot cpu cycles.
[Desire Android Development] woti23:
well there actually is bftrfsck, but wouldn't rely on it, not now

i'm running btrfs on the phone since 2 days, don't see an advantage over ext4, but also no disadvantage, but if something breakes, i mount just partition 0p3 instead of 0p6 rather than trying to compile an arm binary for btrfsck ;-)
[Desire Android Development] woti23:
is alignment somehow doable with gparted? there are 3 options for alignment

none/MiB blocks/cylinders?

to MiB blocks?
[Desire Android Development] woti23:
market does either not accept btrfs for /data/data, or the logical partition.

(no space available error)

moved it back to the first after fat32 partition (ext4) and it works again
[Desire Android Development] melethron:
I ripped your quote apart to answer step by step.

AFAIK nilfs2 is kernel since 2.6.30. Altough the dev didn't DECLARE it stable it stable i didn't found anything about issues. The reason it isn't popular is that there aren't many ssd drives yet and using it on an usb stick doesn't make sense since you can only use it on pc's with the utils. Usb stick needs to be compatible. Also the reason it is not popular is that there are just stupid reviewers out there that used it on a HDD and say it's sucks. That's fail ....

yes it's needed. Nilfs on its own always writes to empty diskspace and never overwrites anything even if marked as deleted. While doing this it makes checkpoints every 5 sec. These are safe states of the disk that can be even be mounted readonly while the actual state is mounted. The garbage cleaner now erases the checkpoints depending on the settings made to it. Check the nilfs site and the manual. They'll explain it.

That wasn't me ... that was sibere.... and i thought it's useless in the first place. I still don't get the reasons he does this.

I also thought about a 1024k alignment. From the info i got for now the max size for the NAND chips in sd-cards is 512k. But i couldn't confirm this. While 512k should be enough for an alignment 1024 doesn't hurt though.

No utils yet for the phone :( . I never cross compiled and since other devs had trouble with this it wouldn't help if i start with it now. Coutts99 is looking at it but he hasn't much time atm. So may take some time to test it.

:( - this would suck if it happens on nilfs too. This is strange.
[Desire Android Development] coutts99:
Still trying to get cross-compile environment set-up :) Think I'm nearly there now though!
[Desire Android Development] Kollegah:
can you make a flashable zip please

i want massivly improved io
[Desire Android Development] vnvman:
At times reading only the thread name before posting is not enough :rolleyes:
[Desire Android Development] Kollegah:
i red the thread title

can you make a flashable zip now??
[Desire Android Development] coutts99:
Read the thread
[Desire Android Development] DroidRevenge:
You are funny!!!

Now read the thread!!!
[Desire Android Development] Kollegah:
i red the whole thread, so can ANYONE PLEASE make a flashable zip file for me?!?!
[Desire Android Development] Abomb:
This thing is not yet finished so there is no update.zip . Please read the thread (at least the first post...) - then it would have been obvious that this is not yet ready.
[Desire Android Development] Kollegah:
okay so what can i do to make my own flashable zip file
[Desire Android Development] mattiadj:
You are very funny.this is a forum of free man and woman and they work hard for make our experience better.

So why and how you can ask in this way for a flashable zip???

If developer want and when they want make it for community and not directly for you!!!!

Say thanks for work, don't ask for other work!!

Regards
[Desire Android Development] coutts99:
Make it work, maybe successfully cross compile nifls2-utils for arm would be a good start.
[Desire Android Development] K900:
Why not btrfs? Official arm support eh :) And just as nice speed with -o ssd
[Desire Android Development] melethron:
Btrfs is the other option i see. Woti ran it for 2 days now. But:
[Desire Android Development] K900:
A kernel issue probably, so I guess we can hack around it. And if it's from git, coutts could be just lucky to catch a broken revision :)
[Desire Android Development] woti23:
im doing a new test serie with postmark

same card 16GB, 2nd partition that contains the various filesystems, 2nd part startsector is n*1024

i'm posting the best result (average from 2nd til 5th run) per filesystem, from the various options i tried

k= kB/s , M= MB/s read first / write last

nilfs2 (mount options default, as described here http://manpages.ubuntu.com/manpages/lucid/man8/mount.nilfs2.8.html)

cfq: 664k / 3.39M

noop: 930k / 4.97M

ext4 (mount options: relatime,barrier=1,data=ordered)

with journal

cfq: 635k / 3.24M

noop: 768k / 3.92M

without journal -O ^has_journal (mount options: relatime)

cfq: 521k / 2.66M

noop: 912k / 4.66M

btrfs (mount options: relatime,ssd)

cfq: 1230k / 6,21M

noop: 1300k / 6.78M
[Desire Android Development] HTF:
So ext4 and nilfs2 are pretty comparable but btrfs is massively faster. I would try for btrfs based on those benchmarks.
[Desire Android Development] woti23:
does someone have fortunatly a binary of lsattr and chattr?

could be usefull at time for make files immutable or append-only, if kernel supports it for ext3/ext4
[Desire Android Development] K900:
Awesome. Simply awesome.

@coutts99 one more btrfs kernel please
[Desire Android Development] woti23:
i think the ssd option for btrfs does some optimization

i will make the test tomorrow again with this 4 variants, to see if its reproducable

i don't know how much the formating between testing influences the results.
[Desire Android Development] K900:
-o ssd does block writes, like nilfs.
[Desire Android Development] NeoPhyTe.x360:
for who likes or will going to try something another one:

kernel with ext2, ext3, ext4, reiserfs, xfs, jfs, btrfs, nilfs2

(file is not signed)

http://www.multiupload.com/VNJ380TXU5

(tried yesterday to compile btrfs binaries but not successfull, it compiles but doesn't works)
[Desire Android Development] K900:
Nice, thanks
[Desire Android Development] ownhere:
Good test.

It seems that 'noop' scheduler is better on flash memory?
[Desire Android Development] melethron:
Again no "SYNC".... these tests are useless if not synced. If sync takes too long then it causes lags .... and thats what i want to avoid ....
[Desire Android Development] melethron:
Indeed. Its the way the controller of an sd card works. If you look at the picture at page 4 on this paper you see that controller usually uses 4 channels. Thats kind of a raid controller. So its better to let this controller do the work. Noop doesn't queue I/O requests at all and simply sends them to the controller. To more I/O requests the better. (But this STILL depends on the controller used).

Also a test without actual sync times is useless. Thats like placebo quadrant.
[Desire Android Development] woti23:
got a new sd card class 10, and will do the test with synced filesystem

seems postmark can't handle that, it takes forever, even with reduced number of files

ext4

15.15 megabytes read (15.95 kilobytes per second)

45.22 megabytes written (47.59 kilobytes per second)

that can't be real, just copied 1GB and unmounted, and that was lesser then 5 minutes

maybe im going to copy random files to ram, and meassure the time it takes to cp to mounted card, if i find no way for postmark
[Desire Android Development] melethron:
Moutning with sync actually sucks. it syncs after every file.

you can make your own bench. just do a

time (copy -ar /files/to/copy/* /mnt/point/of/partition && sync)

this way its only synced after the last file. Mounting with sync is not an option for me so i look for short sync times.
[Desire Android Development] K900:
So, currently we have best results with noop+btrfs. Anyone have a working script? I'm too lazy to build one myself :) Also, @OP: data2nilfs in the topic is no longer the whole idea. Maybe data2sd would be better?
[Desire Android Development] NeoPhyTe.x360:
do u have btrfs binaries to arm? or have you could build it?
[Desire Android Development] K900:
I got them from ubuntu for now, but they don't seem to work. Will try cross-compiling tomorrow
[Desire Android Development] melethron:
Update on OP. Nilfs first impression on desire ....

AGAIN: Benchmarking is useless without sync. Such results are pure placebo (like those fancy quadrant score on a non synced ext 4 loop device - when the phone felt actually slower due too lag). Pls refer to the comparsion of sync times in this post..... I still added btrfs to the title, cause it is really an option. But for now i doubt it is faster due to missing sync comparsion ...
[Desire Android Development] NeoPhyTe.x360:
http://xdaforums.com/showpost.php?p=9786078&postcount=91

Here other kernel to btrfs & nilfs2
[Desire Android Development] melethron:
updated. Thanks i missed that one....
[Desire Android Development] woti23:
time (cp -ar ~/desire-backup/data/app/* /mnt/ && sync)

299MB files from roms, many of them in all various sizes

average from 5 copies with deleting between

btrfs noop : 4.6 MB/s

btrfs cfq : 4.8 MB/s

ext4 noop : 3.2 MB/s

ext4 cfq : 2.6 MB/s

nilfs noop : 5.4 MB/s

nilfs cfq : 3.5 MB/s

ext2 noop : 2.5 MB/s

ext2 cfq : 2.4 MB/s

ext3 noop : 2.8 MB/s

ext3 cfq : 1.34 MB/s
[Desire Android Development] melethron:
thats actually exactly what i expected. btrfs faster for cfq but not on noop. Nilfs should even be faster if you do it with data/data since there are smaller files in there.

Thanks for the test. I still may prefer btrfs over nilfs if battery is an issue. This does look like it will be :

94 0 4:27 /system/bin/nilfs_cleanerd -c /system/etc/nilfs_cleanerd.conf

4:27 min CPU time :( :(

Compared to that i really like what i see on those test. Results from phone:

Card is a Kingston class 2 16 GB card (can vary even on same class)

bash-3.2# cat /sys/block/mmcblk0/queue/scheduler
[noop] bfq
< of=/data/data/ddtest/trash bs=1M count=20 && sync)
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 7.492554 seconds, 2.7MB/s

real 0m7.595s
user 0m0.220s
sys 0m0.190s
< of=/data/data/ddtest/trash bs=1M count=20 && sync)
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 9.744232 seconds, 2.1MB/s

real 0m5.248s
user 0m0.200s
sys 0m0.220s
< of=/data/data/ddtest/trash bs=1M count=20 && sync)
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 8.915405 seconds, 2.2MB/s

real 0m8.988s
user 0m0.140s
sys 0m0.250s
< of=/data/data/ddtest/trash bs=1M count=20 && sync)
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 9.794281 seconds, 2.0MB/s

real 0m9.858s
user 0m0.200s
sys 0m0.150s
< of=/data/data/ddtest/trash bs=1M count=20 && sync)
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 5.199371 seconds, 3.8MB/s

real 0m5.280s
user 0m0.210s
sys 0m0.210s
< of=/data/data/ddtest/trash bs=1M count=20 && sync)
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 6.089844 seconds, 3.3MB/s

real 0m6.171s
user 0m0.190s
sys 0m0.200s
bash-3.2# cd /sdcard/

See those small sync times. This now compared to the fat partition of regular sd:

bash-3.2# time (dd if=/dev/zero of=/sdcard/trash bs=1M count=20 && sync)
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 7.025848 seconds, 2.8MB/s

real 0m8.574s
user 0m0.130s
sys 0m0.290s
bash-3.2# time (dd if=/dev/zero of=/sdcard/trash bs=1M count=20 && sync)
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 7.593109 seconds, 2.6MB/s

real 0m9.160s
user 0m0.170s
sys 0m0.330s
bash-3.2# time (dd if=/dev/zero of=/sdcard/trash bs=1M count=20 && sync)
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 9.975769 seconds, 2.0MB/s

real 0m11.590s
user 0m0.210s
sys 0m0.300s

Almost 2 sec sync times.....

Quadrant score is ~1800 on Lee's Rom (1113mhz) wich is about 150 more for me. And i mean REAL score since those almost instant syncs means that is not placebo.

Im going to experiment if i leave dalvik on internal.
[Desire Android Development] woti23:
another test on phone

cache is in RAM, 24MB copied 5 times with delete between

MB/s

bfq / cfq / noop

ext4

time (cp -ar /cache/android.data /data/data && sync)

6.2 / 4.2 / 6.0

nand

time (cp -ar /cache/android.data /data/ && sync)

3.7 / 3.9 / 4.8

btrfs

time (cp -ar /cache/android.data /system/sd && sync)

6.8 / 5.0 / 7.0

fat32

time (cp -ar /cache/android.data /mnt/sdcard/ && sync)

5.3 / 3.7 / 7.8

scheduler bfq / cfq / noop
[Desire Android Development] K900:
Wow, nice tests. I'm building a FS-agnostic script atm, will test it and report back
[Desire Android Development] woti23:
i'm surprised that nand is slowest, i did compare nand against sdcard with syncing after a month ago, and had the same results, and i have only class 2 card
[Desire Android Development] K900:
I think NAND is not slower, just the kernel is doing it wrong :) I wonder if using some other fs on NAND is possible...
[Desire Android Development] HTF:
I was under the impression that the Desire does use slower nand chips compared to some other android phones so I am not surprised by that.
[Desire Android Development] K900:
DO WANT btrfs on my NAND
[Desire Android Development] melethron:
.... hmm, i never thought about to cache in RAM. Isn't Ram used as r/w cache ....?

Did you just mount /cache on tmpfs ? Are there differences?

Additional info for those that think FAT would be best now. Remember that fat has no journal or any other method to prevent fs corruption. EXT4 without journal would also be much faster.

Other fs on NAND is possible, but only if the kernel supports it. But we need support of the default kernel AND for the recovery Kernel then. If the fs isn't implemented in the kernel of recovery we wouldn't even be able to flash a ROM.

Btrfs on NAND is not a good idea. It's something completly different. The sdcard uses a controller to "simulate" a normal LBA/rotating device. The NAND in the phone is RAW NAND. (BTW. Dont even know if its possible to use btrfs on RAW NAND). For NAND we need completly different approaches.

A dev of #project-voodoo said we should try UBIFS instead of YAFFS2:

(btw: he calls me mekwall in irc bcs of typing "me + TAB" and i wasn't the only one with a name starting with "me..." ^^)

Also Update about Nilfs: Battery is horrible, .... it adds ~1%/h .... i'll go to test btrfs now....
[Desire Android Development] K900:
Btrfs does work on raw NAND, and it should be running nicely. I wonder what that UBIFS is...
[Desire Android Development] HTF:
I read up on ubifs a few weeks ago and it does really look like it would be better for the internal nand. There are quite a few different nand filesystems to choose from though now.
[Desire Android Development] woti23:
i experiment.

i have data++ aplharev mtd resize, so /cache is normaly nand 10MB

which can be to small when downloading from market

so i unmount /cache in init.d and mount it in an (atm its 50MB) tmpfs, with the same permissions as in nand

afaik its only used for market downloads, htcsense.com (i belive)

google perferences.

i constanly get after a while after deleting a file android.data with 24MB in it

for restoring (i didn't dig too much in that until now, so its a little speculating too) things when u wipe your data.

i prefer to restore data myself.

u can safely delete cache if you don't care/rely on syncing your preferences with googleservers or htc com (there is an option in preferences to turn it off i think)

now i have only used it that it meassures just from ram do nand etc, and the read from ram time doesn't matter
[Desire Android Development] melethron:
I also think it will perform well. Since its COW based. But im still a fan of LOG based fs. Also i think a fs made for rotating devices which has optimizations for an ssd controller (like btrfs) should still perform worse than a fs that is made for RAW Nand. But im not sure about this. Ill ask the SGS devs about this.

About UBIFS check this: http://www.linux-mtd.infradead.org/doc/ubifs.html#L_overview
[Desire Android Development] melethron:
Ah ok. Thanks for the info. I also remember that i have read something about cache also beeing used by the internal browser.
[Desire Android Development] woti23:
only com.android.browser uses by default /app-cache which is 8MB tmpfs in ram

i merged both /cache and /app-cache together so i free up 8MB ram