Comment by coldtea
4 years ago
>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]
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.
Now Apple is the primary storage manufacturer for Mac.
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.