[Desire Android Development] sibere:
I'm sorry to tell you that there is quite a few differences between a flash memory based device and a mechanical hard drive. And one of the main ones is this famous erase block size which causes much troubles when partition is not aligned and the FS not tuned to it. An other big one is the very low latency compared to an hdd. So basically where you don't care about block size (512b on a hdd) but you do care about latency, you have to consider the total opposite with flash memory: Big blocks ( could be anything to the power of 2, but I'd reasonably say to not consider anything above 4MB ATM ;) ) and very low latency.

I'd say a phone is not a desktop and data storage devices are much faster in desktops that in our poor little devices. Would it make sense? ;)

I can't say anything about desire HD or nokia phones b/c I don't have those phones.

But what I can say about desire is that the NAND performance is pretty poor. Is it because it's journaled? Or is it because of a bad hardware? I dunno but surely both.

HTC devs have been very clever and decided to unmount properly /data before turning off the phone. Apparently it's not the case for other manufacturers.

If this wasn't the case, I would for sure use a journaled FS.

Is nokia unmounting /data properly? Did google implemented this clean unmount in gingerbread? Well I dunno but I hope that they did. Designing previous versions without this feature was a bad idea IMHO.

Talking about journal, be careful. It's not because the system is mounted with default options that there is a journal :) Look at my very simple and basic script. I don't use any journal option except the "nobh". You could then assume (booooo this is bad) that I use standard options. And this would be untrue because I disabled journal at the mke2fs stage. But I'm not saying that's what google is doing , it's just to show that we cannot rely only on mount options to figure out everything. I'd rather use a tune2fs -l on the FS :)

The thing about journaling here is that I always said that I wanted on my script and on my thread to use an unjournaled FS (life on the edge do you remember? ;) ) for a better performance. But I'm giving to users the option to enable it. I know that you prefer playing that game the other way round and offering unjournaled FS as an option. But what I'm saying is that this is from start a thread about unjournaled FS so I don't see why you're coming here every now and then, running like mad in circles with hands to the sky , shouting that unjournaled fs is devil and you'll never play with fire and users are going to die if they don't use journaled FS. (maybe I should use the [irony] tag here ;) )

:D

Well, this is a shout after all... If someone shouts at you saying "I LOVE YOU" you'll surely won't feel it at being aggressive. If the shout is "WHAT YOU DO AND SAY IS ****" I'm pretty sure that your feeling will be different, isn't it?

You're 100% right. But my point with the RAID options is not data sorting and scheduling, but erase block size, which is completely different. This why I don't understand why you're talking about the way the controller spreads the data over the internal channels when my subject is block size. Whether there is 2 or 4 or 6 chans, if the erase block size is - say - 256kb, if 10kb of data is written, the controller will have to write the entire 256kb block anyway.

Strip-width as noting to do with data scheduling but block allocation. The internal number of channels is pointless here.

(snipped a few lines)

Ok so you decided on your own that 1Mb alignment was safe enough. But you're not sure... But you consider your decision safe and acceptable. Maybe the best choice is 2mb? Maybe for this big 32mb card it's 4mb? You don't know and I don't know either. That's why I decided on my own that 256kb data block size was safe enough and I don't understand why you did complain about that and you consider my decision unacceptable and a fail on the basis of your ignorance.

Neither you do, but you choose 1Mb alignment "for all"... do we have to consider it as a fail too?

Anyway, open the document you posted (SD/SDHC/SDXC standards) and you go to page 101 of this document. You've missed some very useful informations.

I've copied them here for convenience:

SECTOR_SIZE

The size of an erasable sector. The content of this register is a 7-bit binary coded value, defining the

number of write blocks (see WRITE_BL_LEN). The actual size is computed by increasing this number

by one. A value of zero means one write block, 127 means 128 write blocks.

7 bits= 1111111 = 127 (+1) = 128 max write blocks right?

LEN_BL_WRITE

The maximum write data block length is computed as 2WRITE_BL_LEN. The maximum block length might

therefore be in the range from 512 to 2048 bytes. Write Block Length of 512 bytes is always supported.

Note that in the SD Memory Card, the WRITE_BL_LEN is always equal to READ_BL_LEN.

So a maximum of 128 blocks of max 2048 bytes = 256KB ! What a chance! ;)

So you can see that this number is not coming from nowhere.

Absolutely. This is why I run my own tests with and without the RAID options. And guess what? I got a big speed improvement with those options. This is not a bench on the net, it's my real life experience because I didn't want to take those benches for granted. Did you try it before coming here and asserting that I'm wrong and those options are useless?

Wow you're using a murderer FS!!! baaaad! :D

I know that reiserFS is not exotic, but btrfs and nilfs are. They're still experimental and shouldn't be of interest if safety is the main goal.

Thanks to ownhere for sqlite, I have both: Fast read/write with 256kb block allocation and fast sqlite inserts. What a wonderful world ! :)