[Desire Android Development] sibere:
I wasn't talking about FAT here. Fat is gone. I was talking about ext2 and you're answering on FAT. anyway. The subject here is why are you complaining that I don't use journal on ext4 and you didn't when ext2 was used?

Talking about programming FS. Those FS have been mainly designed originally with standard mechanical drive in mind. They're prone to fail and corrupt data much easily than flash memory. In that situation, a journaled FS is a great help at keeping data integrity. And keep in mind the "environment". We're not talking about huge data centers but a little personal device called a smartphone. In first case scenario, data integrity cannot be jeopardised for performance. In the second one, it can. And specially because our device is a poor performance one.

But in a professional environment, I would 100% agree with you and by no means use something else than an journaled FS and a daily backup.

I'm not interpreting , that's internet rule :)

use CTRL B for bold then ;)

Wow congrats :)

I might be wrong here but to me, as the SD is considered as a block device, you can use a much data channels as you like, but the data flow will be converted at some stage before reaching the SD in a single channel data flow. Then the SD controler on board of the SD spreads the data internally to the number of channels the manufacturer choose.

read further to page 7

I quote:

Reading and writing to an SD Card and MultiMediaCard is generally done in 512 byte

blocks, however, erasing often occurs in much larger blocks. The NAND architecture

used by SanDisk and other card vendors currently has Erase Block sizes of (32) or (64)

512 byte blocks, depending on card capacity. In order to re-write a single 512 byte block,

all other blocks belonging to the same Erase Block will be simultaneously erased and

need to be rewritten

Erase block size is a physical consideration, specially for MLC memory. So if you consider the "SD Card Physical Layer System Specification" out of interest, there is nothing I can do for you ;)

We can play as end-users with the block size parameter but not the bus frequency. This is out of interest here.

There is actually softwares which can read the SD card registers and give the physical erase block size for a given card. You can use one of them to find the erase block size of your card and let me know if you find something above 256Kb even for a 32GB card. If so I will put with great pleasure a note on the OP to adapt the formatting options accordingly.

Of course we don't have control on the way the internal controller allocates blocks. They're surely not contiguous (wear levelling) but we don't care about this thanks to the very low latency. That's why file fragmentation is not an issue on flash memory. But the writing process will always be by a physical block whether the process writes 1 byte or 256kb. That's why it sounds better to me to optimise this process and write as much as 256Kb of data per writing process than 4Kb or less when possible. Obviously enough, if one process only writes say 512 bytes, block size optimizations will be useless.

Ok let's make it simple.

First I don't know about those FS, I've used EXT4 options and I don't want ATM to spend more time at playing around with exotic FS.

Why do you align your partitions in you script? because of... yes you got it the erase block size! Why do I use the RAID options? Same answer: the erase block size. It has always been observed that writing aligned data to the erase block size of the device improves the performance.

I'm not gonna get deeper into the code of the kernel and the ext4 driver. this is far beyond my skills. I'm a simple user and observer. What I am sure of is that I almost double my write speed by using those parameters and writing 256Kb aligned blocks of data instead of the default 4kb.

It doesn't mean that if it's working for me, it'll work for you.

but all the posts I've read about optimizing EXT4 for flash memory based devices ended up with the conclusion (with benches) that RAID options improved things. That's what I say and nothing else. I'm not and never will pretend to be the one who discovered the graal ;)

For the data base inserts, surely reiserFS is better than ext4, but I'm happy with the great hack ownhere did on the sq3 lib.