7 ms·
> 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 ch
by comex 10y ago
> 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.
- ChuckMcM 10y agoNot 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.
- quotemstr 10y ago> 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.
- jrockway 10y agoLinux has PRINTK_PERSIST [1] to recover the printk logs after (warm) reboot. [1] https://lkml.org/lkml/2012/3/13/45 https://lkml.org/lkml/2012/3/13/45
- reitanqild 10y agoSomething related though battery (or capacitor) backed write-cache on high end servers.
- derefr 10y ago> 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.
- ygra 10y agoI 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.
- iopq 10y ago> 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.
- awjr 10y agoI 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.
- josephg 10y agoApparently 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.
- marvy 10y agoMe 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.
- digi_owl 10y agoI 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.
- bmm6o 10y agoThis 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.
- pvg 10y agoIn 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.
- sbierwagen 10y agofsync() 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/ https://danluu.com/file-consistency/ http://blog.httrack.com/blog/2013/11/15/everything-you-always-wanted-to-know-about-fsync/ 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 https://en.wikipedia.org/wiki/Flash_file_system
- quotemstr 10y agoThe 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.
- ioltas 10y agoOr in short, calling fsync() twice is a tweak under-known: the file itself needs to be flushed, as well as its parent directory.
- chillaxtian 10y ago> 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?
- elktea 10y agoThreads are hard, basically.
- umanwizard 10y agoI 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
- azernik 10y agofsync() 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.
- quotemstr 10y agoBecause 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/StrictMode.html https://developer.android.com/reference/android/os/StrictMod...
- digi_owl 10y agoEven 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.
- busterarm 10y agoI 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.
- c8g 10y agoor developer had to build separate app for x86, armv7, armv5, armv6, armv8, mips,...
- deleted 10y ago[deleted]
- busterarm 10y agoReally just arm* until the last couple of years. These choices were made forever ago.
- sangnoir 10y 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.
- rrego 10y agoSo from reading the XFS FAQ linked in the article(http://xfs.org/index.php/XFS_FAQ#Write_barrier_support. 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.
- idrae 10y agoYes, it has to be flushed from time to time. Normally this happens automatically when it is needed. fsync() just forces a direct flush.
- macspoofing 10y ago>In other words, because the Moto Z cheats. If you're not cheating, you're not doing it right.