Android 2.3 to use ext4 | Hacker News Reader

Android 2.3 to use ext4

android-developers.blogspot.com

35 pointsdmaz12 comments

I'm confused. A few years ago, the perceived wisdom was that dedicated flash filesystems like yaffs2/jffs are better (performance & longevity-wise) for running on flash devices than more general block filesystems like ext4/3/2.

What am I missing here? Are flash controllers, or the mtdblock kernel layer, now smarter than they were previously?

The dedicated flash filesystems are designed to run directly (or separated by only a very thin layer of abstraction, e.g. the mtdblock you mentioned) on flash chips, so they take care of wear-leveling and use flash-friendly data structures.

Most modern phones these days run off sd-cards that take care of all these issues, and it looks like the algorithms embedded in these small cards, combined with normal off-the-shelf filesystems deliver better performance and better reliability than what the special-purpose filesystems could.

Although how does this explain the Nexus S, which is using an embedded 16G flash chip instead of an SD card? Are there equivalent wear-leveling algorithms included with modern flash controllers?

I don't know specifically for the Nexus S, but as a manufacturer you can buy flash-chips that have a mmc interface, so that they look like an SD-card to the microprocessor but can be soldered like a "usual" chip.

E.g. look for SanDisk iNAND.

some very rough filesystem comparisons on a samsung captivate:

http://forum.xda-developers.com/showpost.php?p=7647224&p...

jfs total: 73.82s xfs total: 39.58s ext4 total: 30.60s nilfs2 total: 17.95s

If those hold up in general, perhaps it came from something as simple as an engineer benchmarking all the options.

I wonder if the nand fs design goals matter as much in a world where your kernel doesn't panic, you never* lose power unexpectedly and phones have a 2 year lifespan.

It's funny how the poster of that article came to the conclusion that a relatively new and not well-known filesystem was safe to use after two reboots and one battery removal.

If something is twice as fast as something else, with all likelihood, the faster thing to some extent does less than the slower thing.

If "less" in this case is stuff for which there is no need on a small device with low storage capacity, then, fine, he's right to use it.

If however "less" is less protection against data loss in edge cases, then this was a risky choice indeed.

He should at least have tried removing the battery while the phone was provably busy actually writing to the filesystem.

The joys of web forum based "development" done by "experts"

The joys of web forum based "development" done by "experts"

As enjoyable as comments on forums about how poorly researched comments on forums are?

(I don't think the guy was using his comment to advocate that everyone immediately reformat their phones. I think the idea was, "this idea is worth researching in more detail".)

NILFS, as a log-structured filesystem, is particularly well suited for flash storage. Its performance wouldn't be nearly as good on a spinning rust benchmark.

I'd always thought that a log-structured filesystem is uniquely suited to spinning rust drives, as it never has to seek its head---it just keeps writing.

No, actually it's ideally suited for SSD because it never write twice to the same place and manage garbage collection in an SSD-friendly way (wear-leveling). NILFS has been enhanced with SSDs in mind lately.

"There are several layers of buffering between you and the hardware!"

I hope this does not come as a surprise to anyone.

Nevertheless, there were a lot of dramas when ext4 first came across to the mainstream Linux distros (as per the extra reading links in the blog post.)

So I can see why Google want to make it perfectly clear that this is happening.

Reply on news.ycombinator.com