[archivator]

This articles conflates a lot of things but it also has the priorities somewhat wrong.

1) fsync cost. Yes, fsyncs are dangerously slow in any Android app. (SQLite for example is a common culprit. Shared Prefs are another). HOWEVER, it's possible that flushes cause reads to be queued behind them (either in the kernel or on the device itself) which is even worse because

2) Random read cost is super super important. Android mmap's literally everything and demand paging is particularly common AND horrendous as a workflow. To add insult to injury, Android does not madvise the byte code or the resources as MADV_RANDOM, so read-ahead (or read-around) kicks in and you end up paging in 16KB-32KB where you only wanted 4KB.

Also, history has shown custom flash-based file system on Android to be a world of pain. yaffs, jffs have some pretty atrocious bugs/quirks. I'd much rather see the world unify on common file systems, optimized for flash-like storage, rather than OEMs shipping their own in-house broken file "systems" (I'm looking at you, Samsung).

[jhasse]

Why can't f2fs be that common file system?

[jdcarter]

I just read the F2FS paper and it seems very well-designed to match the physical properties of flash, plus some interesting capabilities to keep hot/cold data separate. If there's something wrong with F2FS, let's fix it. This seems like a far better place to start from than any filesystem designed around the assumptions of a spinning disk.

[TazeTSchnitzel]

It's in the mainline Linux kernel now, it's hardly some proprietary obscure vendor thing.

[archivator]

That's fair, it's a better state than the previous attempts.

Still, it's not as tested as, say btrfs and ext4. Can't wait to see its particular quirks.

[cbsmith]

While it no doubt impacts performance in some cases, MADV_RANDOM probably isn't the correct choice for a lot of circumstances (the classloader tends to do a linear scan of JAR files, for example).

[archivator]

Except that's not how class linking works on Android :)

In particular, everything is compiled down to lookup tables and hash tables within each odex/oat. Your point still stands but the hit is much lower than you would think and given the slow speed of the superfluous reads, it ends up being a net positive for A LOT of cases.

[cbsmith]

Well, during verification, you very much do a linear scan as I described. Of course, you only verify once, so that minimizes that use case.

The way odex files are structured, there is actually a fair bit of data sequentially organized (for example dependencies), even with the indexing. The odex format does seem to have some elements that anticipate read-ahead (e.g.: those hash tables, dependencies...).

That said, there is a real question about proper tuning of read-ahead for flash memory (like, perhaps 4k or even 0-byte read-ahead is the right thing to do in general ;-). It's not like it is hard to abuse it.

[mrich]

> Android mmap's literally everything

Why is that so?

[kllrnohj]

allows code & resources to stay as clean pages because clean pages can be swapped out even though there's no swapfs whereas dirty pages can't (since there's no swapfs).

[cbsmith]

Why would you want it NOT to be so?