Basically, the benchmark is testing a phone that doesn't run the code for fsync vs. a phone that does. The phone that has a no-op for fsync will clearly be faster at not running any code than the one that actually does what the programmer instructed.
It is like asking what is faster:
def sin(x):
return 0
def sin(x):
actually calculate the sin(x)
More generally, how often do you call fsync in your code? I very rarely call it and generally allow the operating system to write the file to disk when it is convenient.
If calling fsync is critical to your application, then the Moto Z has broken your app by making fsync a no-op. If it isn't critical to your application, then why are you calling it?
If you use a database for storing your apps data like sqlite, which you should, then you're doing an fsync on virtually every insert/update operation. One of the main reasons for using a database is that it takes away the headache of deciding when and how to fsync.
If you manage application state yourself, and the phone does power off or kill your app at an unfortunate time, you might up with a corrupted application state. If you're a big company like Facebook or Google with millions of users this will be happening multiple times per day, and produce a slew of complaints about your app.
Depending on the exact mechanism and implementation, making fsync a no-op is not necessarily bad. As long as it can (with highest priority) fsync all of its buffers upon notification of loss of power and be done before all capacitance is lost then there should be no trouble at all. Of course, this requires some coordination between the hardware, the OS and the filesystem which might be non-trivial even for a fully integrated company like Samsung so it could be it simply doesn't work at all like that.
>Depending on the exact mechanism and implementation, making fsync a no-op is not necessarily bad. As long as it can (with highest priority) fsync all of its buffers upon notification of loss of power and be done before all capacitance is lost then there should be no trouble at all.
I'd guess the most popular apps DO use a database on Android, right? So we could make some testable predictions. If the Moto Z's fsync is a no-op, then we should expect more database corruption. So if we don't see database corruption, we can presume a highly prioritized, efficient fsync on power loss notification. Battery pull vs. low battery poweroff event? I'm still thinking about controls and test methodology. Also, either Android app databases don't corrupt often, or they're good at recovery, because I haven't seen app errors (aside from incompatibility) in a long while. Then again, I have a Pixel, not a Moto Z.
I am going to reflash with these filesystem changes though; just not sure how to benchmark.
> If you use a database for storing your apps data like sqlite, which you should, then you're doing an fsync on virtually every insert/update operation. One of the main reasons for using a database is that it takes away the headache of deciding when and how to fsync.
It batches the fsync per transaction, so there's only one fsync for 10000 inserts in one transaction.
> Depending on the exact mechanism and implementation, making fsync a no-op is not necessarily bad. As long as it can (with highest priority) fsync all of its buffers upon notification of loss of power and be done before all capacitance is lost then there should be no trouble at all. Of course, this requires some coordination between the hardware, the OS and the filesystem which might be non-trivial even for a fully integrated company like Samsung so it could be it simply doesn't work at all like that.
It's supposed to work if the OS crashes. Kernel panics are not incredibly uncommon.
(neither a Pixel fan or hater here)