In the 'computer is a phone' perspective there is no sudden power loss unless the user yanks the battery out of the back. That is presumably a rare occurrence for your typical user. As a result, the big risk for phone file systms is that the phone crashes, but nearly every phone I've seen preserves memory contents as long as power is applied, so even a crashed phone, on reboot can pick apart the previous bits in memory and reconstruct what was going on before it crashed.
Given that fairly unique to phone criteria I could see nobarrier as a legit option.
What you're proposing is possible in theory, but no general purpose operating system I've seen actually attempts to recover page cache state from uncleared RAM upon reboot.
I've witnessed a number of phones with the "crumple zone"-alike feature of effectively ejecting the battery cover + battery out of the phone whenever you drop it.
I drop my phone all the time and I don't have a case. It's fine.
It's probably not just bad luck that the glass happened to break after the Nth time you dropped it. It was bound to happen if you kept dropping the device.
I suspect that if I didn't have a case I wouldn't drop it so often.
Do you just lose a new contact, or corrupt an essential database?
How essential are we talking about here?
What I mean is, your smartphone is a device that can get lost, stolen or destroyed any day. All the data that is physically stored in it should either be expendable or synced elsewhere.
Are people creating new contacts that often on a phone? I probably do that only a few times per week. If the phone crashed immediately following the input, I'd just ask the person for their details again.
> corrupt an essential database?
It would only corrupt application data. Android isn't completely stupid, /system is mounted read-only on every Android phone I've ever seen.
I guess it depends on how highly you depend on application data remaining consistent.
Presumably the corruption would only apply to data that was modified but had not been flushed to flash before the power cycle, so at rest data shouldn't be affected.
> I probably do that only a few times per week.
If your data is kept in a SQLite database or any other type of compound storage scheme it's entirely possible to lose data that wasn't being modified, due to corruption of the metadata that governs the layout of the file (actually I don't have experience with SQLite file format specifically, but I ruined my startup's launch a decade ago with almost identical reasoning--thousands of pressed CD-ROMs in the garbage).
Define longer-lived, you'll probably have replaced the battery several times before flash wear becomes an issue
That said, all mobile devices, laptops included, have a "force shutdown" option activated by holding the power button for x seconds.
Or the battery is a couple of years old. Or the user lives someplace where it's cold outside.
Filesystems optimized for flash, and for battery-backed systems in general, (laptops, phones) have some history: https://en.wikipedia.org/wiki/Flash_file_system
But don't listen to me. I like TxF too.
this is the thing that confused me.. why are apps doing disk i/o on the GUI thread?
For example, on iOS, +[CLLocationManager authorizationStatus] (checking if the app is allowed to use location or not) has to read a file [1]. Almost no app developers are aware of this.
[1] I've been told this by guys who worked full-time on location stuff, but I haven't verified it myself and can't find it in docs, so take it with a grain of salt
Wouldn't the cache HAVE to be flushed as it fills up at some point to maintain coherence.
If you're not cheating, you're not doing it right.
They simply do not care about optimizing the performance of the phone running their software. Otherwise they never would have chosen a garbage-collected language like Java for the platform in the first place (I understand they've ameliorated this concern recently). Or used ext4 like here.
Not sure if you're being serious or hyperbolic - but Google bought Android, Inc (an Andy Rubin startup). The team had a lot of Danger alumni - Danger being the makers of the HipTop - aka the original T-Mobile Sidekick (also running Java). I'm certain they knew a thing or two about hardware, they just made trade-offs you disagree with.
In other words, because the Moto Z cheats.
I suppose it's understandable... nobody should ever be blocking GUI animations on fsync, much less two of them in a row, but here we are.