[Galaxy S I9000 General] nCoder:
Did some research in Wikipedia and some technical discussions on the FS system.

Looks like the EXT2 EXT4 aproaches are not the most indicated ones for Flash memory.

EXT2/4 are DISK File Systems While YAFFS is a File system optimized for flash memory, solid state media. (Ref. http://en.wikipedia.org/wiki/List_of_file_systems)

Some quotes from technical guys:

RFS = Robust FAT file system

From the blurb at http://www.samsung.com/Products/Semiconductor/Flash/TechnicalInfo/rfs.htm

this looks a bit like FATFS running on top of DOC. It might have some transactioning which would make it look a bit more like Microsoft's TFAT.

Neither of these are a proven reliable system. DOC can still get FAT corruptions if you don't umount before power loss (== potentially a completely scrambled fs). TFAT is completely unprovedn and is slower and not always robust (not robust with typical mount options). Perhaps RFS gets the robustness right.

Running FAT on NAND costs some performance due to the FTL etc. To make a journaling system on FAT, as RFS claims, costs even more performance.

FAT is indeed "instant mounting" and uses less RAM because it is not log

structured. FAT however does have a bad record as far as reliability and

write speed on raw NAND devices.

IMHO: If you want robustnes on NAND use a log structured fs designed for flash: YAFFS or JFFS2.

I get a lot of feedback that YAFFS is typically a few times faster than JFFS2

Some info about YAFFS:

YAFFS is a robust log-structured file system that holds data integrity as a high priority. A secondary YAFFS goal is high performance. YAFFS will typically outperform most alternatives. It is also designed to be portable and has been used on Linux, WinCE, pSOS, eCos, ThreadX and various special-purpose OSes. A variant 'YAFFS/Direct' is used in situations where there is no OS, embedded OSes and bootloaders: it has the same core filesystem but simpler interfacing to the OS and NAND flash hardware.

The filesystem is licensed both under the GPL and under per-product licenses available from Aleph One.

YAFFS2 marks every newly written block with a sequence number that is monotonically increasing. The sequence of the chunks can be inferred from the block sequence number and the chunk offset within the block. Thereby when YAFFS2 scans the flash and detects multiple chunks that have identical ObjectIDs and ChunkNumbers, it can choose which to use by taking the greatest sequence number. For efficiency reasons YAFFS2 also introduces the concept of shrink headers. For example when a file is resized to a smaller size, YAFFS1 will mark all of the affected chunks as dirty - YAFFS2 cannot do this due to the "write once" rule. YAFFS2 instead writes a "shrink header", which indicates that a certain number of pages before that point are invalid. This lets YAFFS2 reconstruct the final state of the filesystem when the system reboots.

YAFFS2 uses a more abstract definition of the NAND flash allowing it to be used with a wider variety of flash parts with different geometries, bad block handling rules etc.

YAFFS2 now supports "checkpointing" which bypasses normal mount scanning, allowing very fast mount times. Mileage will vary, but mount times of 3 seconds for 2 GB have been reported.

Ref. http://en.wikipedia.org/wiki/YAFFS#YAFFS2

Conclusion

Shouldn't we be exploring an YAFFS2 LagFix (Looks like Samsung is evaluating this alternative too)

EDIT: I saw now a some explanation why we still cannot use this FS in our SGS :(

Anyway... Perhaps some day Samsung realizes the advantages, and makes the step forward.

I can understand now, why it takes so long for Samsung to fix this (if they are really trying).