[Desire Android Development] sibere:
So basically you say:

Don't backup an unjournaled FS but you can use it. If so, use mine, not sibere's one...

This is bull**** and beforehand when I was using ext2, you never protested about making backups of an unjournaled FS. As long as the FS is unmounted properly by the system, there is no real reason to put the integrity of the data in doubt. It's a phone, not a big company server... Journaled is surely safer but slower and add more wear to the SD card.

It also has been reported that in the event of a sudden reboot or power-loss, the journal integrity was not guaranteed.

I would like at this time to remind you that capital letters on internet are interpreted as shouting. And I don't really see the need of shouting here. If you want to put some emphasis on something, please use bold or underline. I feel shouting as being an aggressive behaviour

I also offered the patched libsqlite.so as a recommended option with an already patched version adapted to the stock ROM.

[snipped useless copy of code because it's not relevant on the data2sd topic]

Once again don't shout please.

May I give you a friendly advice? Once again don't make your assumptions as a universal truth. I thought you had learn the lesson with the clean unmount of /data.

For a) who cares? An SD is not considered by the system as a pure NAND like the internal memory is. The controller makes it like a single block device of 512b per block, regardless of the actual SD block size and the number of internal channels. It's the controller job to deal with this. The stripe-width is used there not in the RAID usual way. I'm not a fool or noob and I know that an SD card is not a RAID array. If you prefer, this settings corresponds to a single drive disk RAID array.

For b) I'm sure that you've read the SD standards, don't you? Actually I'd say no otherwise you would have known that per those standards, the maximum erase block size is 256kb. If any manufacturer uses less than 256Kb (ie: 128kb or 64kb or less) blocks, I'm safe enough with 256KB blocks and if a 3rd world manufacturer decided to not follow those standards and uses a 512kb block on his sd card, well, I'm safe to with 2 writes per block instead of tons if I leave the system with default settings (1kb to 4kb block). For instance, SanDisk was using 32 or 64 512bytes erase block sizes (ie: 16kb or 32kb) depending on the card capacity in 2002. Even if they use 128 or 256 blocks of 512bytes, they're still below standard 256kb max erase block size. (see this PDF http://www.flashgenie.net/img/productmanualsdcardv2.2final.pdf) It's better to set 256kb by default than none.

finally for c) You should read the man more carefully. Maybe you've missed the most important information at the end of the stride def: "It may also be used by the block allocator." The stripe-width is used in conjunction because it's a single disk array and goes with the stride command. (Configure the filesystem for a RAID array with stripe-width filesystem blocks per stripe.) And if one wants to use journal, well the parameter is also set ;) The metadata bit is only at mke2fs time btw, but the block allocator is when the FS is mounted and used. I' don't see what you're complaining about? Even if you where right (which is not the case) and the setting was doing nothing (which is also not the case), if the setting is doing nothing then it will hurt nothing. So what's the (your) problem here?

I don't use journal so I don't care about writing metadata. But my interest here is to write 256kb data blocks at a time. I've been through a lot of documentation on the net about EXT4 optimisation with a focus on flash memory and write blocks allocation by the FS.

Maybe you don't know it but using stripe and stride RAID options on a single device is totally doable and with the conjunction of extents leads to a data block allocation. Why did I choose 64 as a parameter? Well simply because with a ext4 block size of 4096 bytes and a stripe/stride of 64, you end up with 64*4096=256KB. This value is then used by the extents block allocator to write 256Kb of data at a time if possible.

As a result, my EXT4 is fast when big files are written. I achieved this way up to 10Mb/s write speed on my class 6 SD card. I never got this score without using stride/stripe and extents. Obviously it is of no help when writing very small files, or sqlite inserts. That's where ownhere hack comes into place.