Comment by lbriner
4 years ago
That's not defence. It fails the principle of least-surprise. If everyone's experience is that fsync is flushing then why would somebody think to look up the docs for Mac in case they do it differently?
4 years ago
That's not defence. It fails the principle of least-surprise. If everyone's experience is that fsync is flushing then why would somebody think to look up the docs for Mac in case they do it differently?
>That's not defence. It fails the principle of least-surprise.
Only if the standard where anything else is a "surprise" is 2022 Linux.
Many (all?) other unices and macOS itself since forever work like that. Including Linux itself in the past [1]
[1] https://lwn.net/Articles/270891/
Drive caches also used to not exist in the past. At that point, behavior was the same as it is on Linux today. It then regressed when drive caches became a thing.
Maybe it not being added to OSes when drive caches came into the picture was arguably a bug, and Linux has been the first OS to fix it properly. macOS instead introduced new, non-buggy behavior, and left the buggy one behind :-)
> Drive caches also used to not exist in the past. At that point, behavior was the same as it is on Linux today. It then regressed when drive caches became a thing.
You mean in the 1980s? Linux wasn’t used before this wasn’t a concern for sysadmins and DBAs. This concern has been raised for years - back in the PowerPC era the numbers were lower but you had the same arguments about whether Apple had made the right trade-offs, or Linux or Solaris, etc.
Given the extreme rarity of filesystem corruption being a problem these days, one might conclude that the engineers who made the assumption that batteries covered laptop users and anyone who cares about this will be using clustering / UPS were correct.
The minute storage manufacturers introduced drive caches is the minute this bug became the responsibility of storage manufacturers. IMO it’s not the kernel’s responsibility.
1 reply →
Any references for Unices traditionally skipping FUA or synchronize cache to the storage stack? Sounds surprising to me. Here's Solaris for example: https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSDiskWrit...
Also re Linux here's eg PostgreSQL 9.0 documentation saying ext4/zfs + scsi used the "SYNCHRONIZE CACHE" command with fsync even back then, and a equivalent SATA command being used by the storage stack with SATA-6 and later drives: https://www.postgresql.org/docs/9.0/wal-reliability.html
On ZFS on Solaris / Illumos you get a choice of whether fsync() acts as a write barrier or actually waits for writes to complete.
They do it according to POSIX spec. Linux is the oddball here.
The POSIX spec is deliberately ambiguous about this.
So? Did Linux do it like that before?
https://lwn.net/Articles/270891/
9 replies →
> That's not defence. It fails the principle of least-surprise.
Welcome to C APIs in general, and POSIX in particular.
> why would somebody think to look up the docs
It seems reckless to me to not do this when you're interacting with the filesystem using low-level APIs (i.e not via Swift/Obj-C).
Linux only stopped doing the clearly wrong thing in 2008 or so iirc.
It is still dumb that there's a definition of fsync() that does not sync :-/
I’d argue maybe .5% of people are working on something where this is even close to being a concern. Those people probably know what they need to use.
Apple doesn’t need to defend anything.
I am sick of this callous and capricious disrespect for users and their data, rampant throughtout this wanky industry.
Do lawyers use Apple computers? Do they work on important documents relating to life and death?
Some people have literally been executed because developers couldn't do their job properly. People have been sent to jail for decades because developers fucked up in the british postmaster scandal.
Average people life in a dangerous world- work with documents about their financial wellbeing. They live in opressive countries where being gay is punishable by death. They drive 2 ton death machines. And now that we have put computers in places where life and limb depends on them, we are responsible for doing the job properly, that's why we get paid.