[Desire Android Development] melethron:
I refered to my fat critic here because fat is an unjournaled filesystem. About ext2 i only used it to test and never recommended it. I can live with data=writeback if there is a performance increase but i won't use an unjournaled filesystem.

That was the intention of stuff like barriers to prevent a "bad" sorting of journal commits (write journal before data etc). But apart from that there is no difference between flash memory and a hdd.

Well then why is a journaled fileystems used in desktop environments?

Yaffs is journaled (desire)

ext3 is journaled (desire HD)

UBIFS is journaled (nokia N9000)

Well lets see what google did in Android 2.3

http://android-developers.blogspot.com/2010/12/saving-data-safely.html

They even fear the large buffering of ext4 and advice people to use more fsync(). Not a problem on sqlite they say... because they fsync after every insert (and ownhere hacked that ;) ). Well but lets take a look what google uses for ext4. Lets check nexus S ramdisk:

on fs
mkdir /efs 0775 radio radio
mount yaffs2 mtd@efs /efs nosuid nodev
chmod 770 /efs/bluetooth
chmod 770 /efs/imei
mount ext4 /dev/block/platform/s3c-sdhci.0/by-name/system /system wait ro
mount ext4 /dev/block/platform/s3c-sdhci.0/by-name/userdata /data wait noatime nosuid nodev

Default mount options considering the journal. That means an ordered journal. Not even writeback. And they say devs should call fsync even more on ext4..... don't they know that this is a phone and not a "professional server environment" (you would wonder what they use there ;) )

Sibere, lets cut this. If you want to use an unjournaled fs then do so. I wont ... and i wont include that in my rom .... and (bold ;) ) i wont make a zip for that ....

Now that you say it, ... i think that guy yells at me and doesnt like my rom.....

I meant the channels of the internal controller. Because that sorts the i/o request by itself through up to 4 channels presorting by a scheduler is useless then. More about that in that posting:

http://xdaforums.com/showpost.php?p=9959265&postcount=257

LOL. Maybe you care about the "SD Card Physical Layer System Specification v2.0" but your card doesn't .... my card is 16GB and this is larger than the 2gb max from the specs you quote. Apart from the larger size there is something that is called SDHC and it was introduced before there was an official standard for that.

When you realize that we have the year 2011 and not 2006 you may take note of the updated specification which includes SDHC and SDXC. And as i already said there is no info on the erase block size:

http://www.sdcard.org/developers/te...lified_Specification_Ver3.01_Final_100518.pdf

If you managed to get an 6 year old SDcard (not microSD .... v2.0 had no specs for that) with a size under 2 Gb in your phone ... well congrats ....

I have an microSDHC and i respect the "Physical Layer Simplified Specification

Ver3.01

"

Since i didn't find

reliable

info on the the eraseblock size used i decided to use 1 mib alignement. There is no "real" disadvantage from that apart the 992kb (2048-63 sectors) missing at the disk start compared to no alignement or 768kb compared to 256kb alignement.

I'll try to make a same script for sh. If i done that my alignment script will check erase-block size. Till then i use 1024k to make sure. As i said my reason for that is not getting reliable info.

Don't take benches from internet to seriously. I wasted some time because of benches i couldn't reproduce (nilfs). Can you give me some links on that. I may test it somewhere in future. But as i said i'm pretty sure it will be the same disappointment that nilfs was.

But writes on larger files aren't in my focus anyway. Those tiny little sqlite inserts in combination with large erase blocks it what needs to be attended. The best thing would be a sd-card with build in write cache with barrier support... then i would use ext4 ordered journal with barriers. That would be save and the write cache would speed things up. Since there are no such cards yet i stick to a "exotic" filesystem (reiserfs isn't that exotic btw it was even standard on SUSE linux which isn't an "exotic" distribution). If reiser4 would be developed more activitly (hans reiser killed his wife because his fs was so fast on sqlite inserts :p ) then this would be seen far more often.