[Desire Android Development] th3:
13 pages to read... You guys have too much free time :P

Those are old tests though. Newer and latest SSD tests throughout kernels all show Btrfs/NILFS being much inferior to EXT4. Except for small, random writes - where the FTL using NAND designed filesystems do better. That test was with a HDD in June 2009.

These are filesystem benches with a good SSD;

Nov 2010: http://www.phoronix.com/scan.php?page=article&item=linux_kqzfs_benchmarks&num=1

Nov 2010: http://www.phoronix.com/scan.php?page=article&item=linux_2637_ext4btrfs&num=1

Sept 2010: http://www.phoronix.com/scan.php?page=article&item=linux_2636_btrfs&num=1

Aug 2010: http://www.phoronix.com/scan.php?page=article&item=btrfs_compress_2635&num=1

Aug 2010: http://www.phoronix.com/scan.php?page=article&item=btrfs_zfs_ssd&num=1

Aug 2010: http://www.phoronix.com/scan.php?page=article&item=zfs_fuse_performance&num=1

Jun 2010: http://www.phoronix.com/scan.php?page=article&item=linux2635_btrfs&num=1

With a good USB Flash drive;

Nov 2009: http://www.phoronix.com/scan.php?page=article&item=linux_usb_fs&num=1

Look at how bad Btrfs performance regressions were through builds. What those tests all show is opposite to the results woti23 has been getting though which was confusing me.

Yea but you have to be careful in relying on these PDF links completely because they are kinda outdated for the NAND/kernel currently being used in 2010. Even in regards to bus width, bus speed, page/block size, write caching, P/E cycles, management algorithms, write amplification, etc... much has changed (improved). Right now, controller implementations utilize 4-12 parallel channels. Companies don't like to give details so we don't mostly know what each uses for current shipping tech.

If you want to understand the internal flash on our phones, many details can be seen here by SanDisk: http://www.reactivedata.com/Product...rialEmbeddedSSD/mDOC_H3_Data_Sheet_Rev1.2.pdf

http://www.rockbox.org/wiki/pub/Main/SansaConnect/1082502_SANDISK_1512.pdf

The latest embedded flash is quoted at much higher performance than woti23's benches: http://www.reactivedata.com/Products/Datasheets/Sandisk/IndustrialEmbeddedSSD/EFD_Brochure.pdf

http://www.sandisk.com/media/57232/Embedded-ENG.pdf

So it looks like the Desire is using older consumer grade internal NAND tech, like 2-3 years old.

- Bad block management, wear levelling, garbage collection and write amplification are the most critical aspects to NAND cell longevity/performance. All controlled by internal software part of the NAND (like TrueFFS). Write amplification is only close to 1.1x for the best elite SSDs. Most of these USB NAND chips will have around a 1.15-1.5x amplificaton. It means, for every 1 host write, 1.15-1.5 writes are really written to flash. You have to take this in account.

- For every write to a NAND cell, it has to calculate ECC bits on every 512b of data and also write them to NAND. It's not just your data being written.

- All NAND performance degrades the more the capacity is full/dirty (i.e. a little bit is talked about here: http://dl.google.com/googleio/2010/android-writing-zippy-android-apps.pdf)

- All NAND has extra spare area for ECC and bad block management (even though you can't see it).

- Write is not the only limitation or problem with NAND i.e.

i) Writing to one cell can "program disturb" kill/corrupt adjacent cell(s).

ii) Too many continuous reads on a cell can kill it or adjacent cell(s).

So because of these problems, your NAND device will be moving not just new data it wants to write, but already written data around blocks too (read->buffer->erase->write->read->verify).

Yes. Stability, reliability, longevity, fluidity/responsiveness and performance. You can't kill any of the first four for the last one.

As Google lately mentioned and talked about, I think the scheduling has a huge impact on performance/fluidity/responsiveness. You can get high performance with large stalls/spikes/lags by dedicating high CPU-disk resources to one process, or you can have good enough performance with excellent fluidity and reponsiveness by balancing CPU-disk resources efficiently between processes. Remember this recent patch did a very similar thing and improved usage under loads massively. The filesystems being checked out here, might perform faster but if they pull more CPU-disk resources than what we presently have, they'll induce lag -> the biggest smartphone demon :)

Yea, he can only report what he finds and I applaud him for testing->sharing. But something else is happening underneath. Like CPU wait or the write files being buffered to be burst-wrote sequentially.

Did they try with delay allocation disabled? It's an additional option to writeback.

Those simple corruptions should have been detected and fixed by ECC internal to the NAND. That's strange.

And to what some others mentioned; UBIFS, YAFFS and such are only for raw flash, not block level devices like SD cards. UBIFS looks great for replacing YAFFS for the internal NAND. YAFFS induces many delays, only one disk op in-flight at a time, etc. These were some old tests ran for raw flash filesystems that some of you may remember: http://free-electrons.com/pub/conferences/2008/elce/flash-filesystems.pdf