4 ms·

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. (SQL

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 10y ago
Why can't f2fs be that common file system?
- jdcarter 10y ago
  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 10y ago
  It's in the mainline Linux kernel now, it's hardly some proprietary obscure vendor thing.
  - archivator 10y ago
    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.
mrich 10y ago
> Android mmap's literally everything Why is that so?
- kllrnohj 10y ago
  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 10y ago
  Why would you want it NOT to be so?
cbsmith 10y ago
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 10y ago
  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 10y ago
    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.

jhasse 10y ago

Why can't f2fs be that common file system?

jdcarter 10y ago
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 10y ago
It's in the mainline Linux kernel now, it's hardly some proprietary obscure vendor thing.
- archivator 10y ago
  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.

mrich 10y ago

> Android mmap's literally everything Why is that so?

kllrnohj 10y ago
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 10y ago
Why would you want it NOT to be so?

cbsmith 10y ago

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 10y ago
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 10y ago
  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.