Hacker News Reader

Comment by comex | Hacker News Reader

> The key option is nobarrier. This effectively makes fsync() a no-op and explains most of the difference in performance.

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.

View on HN

Not exactly a cheat. A calculated risk. A friend of mine were having the storage discussion on phones and realized that phones never really experience a 'power outage' in normal use. People use their phones, they get low in power, and then they plug them in. Or the battery gets so low the phone shuts itself off in an orderly manner.

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.

> reboot can pick apart the previous bits in memory and reconstruct what was going on before it crashed

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.

Linux has PRINTK_PERSIST [1] to recover the printk logs after (warm) reboot.

[1] https://lkml.org/lkml/2012/3/13/45

Something related though battery (or capacitor) backed write-cache on high end servers.

> unless the user yanks the battery out of the back. That is presumably a rare occurrence for your typical user.

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 would hope dropping a phone is also a rare occurrence for typical phone users. Otherwise they're probably better off getting a Nokia 3210 instead of a smartphone with glass screen.

> I would hope dropping a phone is also a rare occurrence for typical phone users.

I drop my phone all the time and I don't have a case. It's fine.

I dropped my phone at the weekend without a case. I now have a shattered screen. :/ It's about the 5th time I've dropped my phone and this is the first time something like this has happened.

Apparently the glass in phone screens develops micro fractures from being dropped. (Well, from hitting the ground). You can't see them with the naked eye, but they weaken the glass and they grow with each successive drop.

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.

Me too, though the screen did get a small crack once. If there was a 1% chance of file system corruption each time I dropped my phone, it would have happened to me by now, I think. And usually when I drop my phone, the battery comes out. It used to happen only half the time, but I think the cover got loosened as a result of all the times I dropped it, so now the battery falls out pretty much every time.

It's 2016, if you abruptly shut down a computer in the middle of a filesystem write the chances of ending up with a corrupted filesystem are of around a 0 %, so those are the chances of getting a brick when you drop your mobile.

If you mount with nobarrier I'd say that the chances are somewhat higher than 0%

Not with any filesystem with a proper journaling system. Filesystem corruption is almost impossible.

Barriers are what force the journal to be written consistently, and IIRC they were enabled by default after 2.6.31 because of corruption with ext4.

you could have corruption and not know. i'm pretty sure on the mac hfs+ corrupts files all the time (why? i've run into it multiple times). but it's not necessarily something you'll immediately notice.

That's upsetting. I'll try not to drop my phone while an update is in progress in that case.

Carpet or hard floor (ceramic, etc) ?

Wood floor and sometimes concrete. I don't drop it from my hand, usually from a pocket or lap, though.

What phone do you have?

Moto G, 3rd gen

Hah, I have 2nd gen. I drop it pretty often too. Slippery black plastic back.

I drop my phone with unnerving regularity, but I use a case and it's always fine.

I suspect that if I didn't have a case I wouldn't drop it so often.

I have to go with the article's position, though - I'd rather have the few seconds data loss and get the better responsiveness and a longer-lived device.

It all depends which few seconds of data are lost, though, right?

Do you just lose a new contact, or corrupt an essential database?

> Do you just lose a new contact

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.

> at rest data shouldn't be modified

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).

  >  I probably do that only a few times per week.

Look at Mr. Popular over here.

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

Something could be corrupted and then that corrupted data could be synced to the cloud, trashing what you had there.

>longer-lived device.

Define longer-lived, you'll probably have replaced the battery several times before flash wear becomes an issue

I've seen this too, but the Moto Z is not one of these phones (the battery is not "user"-removable).

I have noticed this with a cheap Window tablet i acquired recently. Left alone it will eventually hibernate, something my Android tablets have never attempted. Similarly, when it goes below 4% battery it will basically force a hibernate.

That said, all mobile devices, laptops included, have a "force shutdown" option activated by holding the power button for x seconds.

This is true for the first few years, but aging batteries can cause problems. My phone is in a situation where under higher power draws (GPS + navigation) it will simply die when the battery falls to 25%. It's been doing this pretty reliably for a month or 2.

In the 'computer is a phone' perspective there is no sudden power loss unless the user yanks the battery out of the back.

Or the battery is a couple of years old. Or the user lives someplace where it's cold outside.

Neither of those should cause a sudden power loss. Even if your battery rapidly depletes, the phone will still shut itself down properly before it loses power.

It shouldn't yet sometimes it does.

fsync() has never been as reliable as the name implies, since flushing the disk cache kills performance system-wide. Fuzziness on what fsync does has... side effects: https://danluu.com/file-consistency/ http://blog.httrack.com/blog/2013/11/15/everything-you-alway...

Filesystems optimized for flash, and for battery-backed systems in general, (laptops, phones) have some history: https://en.wikipedia.org/wiki/Flash_file_system

The fundamental problem is that fsync is too powerful. Most of the time, what you really want is a write barrier --- you don't care about when writes happen, but you do care about their order. fsync is a write barrier, but it's also a synchronous flush.

But don't listen to me. I like TxF too.

Or in short, calling fsync() twice is a tweak under-known: the file itself needs to be flushed, as well as its parent directory.

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

this is the thing that confused me.. why are apps doing disk i/o on the GUI thread?

Threads are hard, basically.

I think lots of stuff causes disk I/O that you might not even be aware of.

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

fsync() in particular is usually only called on (well, after) disk writes though - I can see that being involved in all kinds of system API calls too, but hopefully the system makers would be savvy enough to use an actual write barrier instead of being fsync-happy.

Because they don't care enough not to. There are even developer tools to help applications not do work on the UI thread: https://developer.android.com/reference/android/os/StrictMod...

Even if they don't, the kernel will likely drop everything to get that fsync out of the way. So a fsync happy app that is doing a file write in the background can cause the whole UI to lag because the kernel is busy dealing with said fsync call.

So from reading the XFS FAQ linked in the article(http://xfs.org/index.php/XFS_FAQ#Write_barrier_support.), does this mean that Moto Z never flushes the cache to disk?

Wouldn't the cache HAVE to be flushed as it fills up at some point to maintain coherence.

Yes, it has to be flushed from time to time. Normally this happens automatically when it is needed. fsync() just forces a direct flush.

>In other words, because the Moto Z cheats.

If you're not cheating, you're not doing it right.

I wouldn't really say Moto Z cheats so much as that Google designed the entire software ecosystem of Android without ever talking to a hardware engineer.

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.

or developer had to build separate app for x86, armv7, armv5, armv6, armv8, mips,...

Really just arm* until the last couple of years. These choices were made forever ago.

> I wouldn't really say Moto Z cheats so much as that Google designed the entire software ecosystem of Android without ever talking to a hardware engineer

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.

Reply on news.ycombinator.com