is that a correct understanding? if so, is that a reasonable risk i see (filesystem corruption at times)?
Unfortunately, most consumer-grade mass storage devices lie about syncing. Disk drives will report that content is safely on persistent media as soon as it reaches the track buffer and before actually being written to oxide. This makes the disk drives seem to operate faster (which is vitally important to the manufacturer so that they can show good benchmark numbers in trade magazines). And in fairness, the lie normally causes no harm, as long as there is no power loss or hard reset prior to the track buffer actually being written to oxide. But if a power loss or hard reset does occur, and if that results in content that was written after a sync reaching oxide while content written before the sync is still in a track buffer, then database corruption can occur.
… part of me hopes there's a very special hell for the people making disks where the OS can never be sure if the data is safe or not.
Early Intel SSDs were known to be particularly prone to this issue: http://www.mysqlperformanceblog.com/2009/03/02/ssd-xfs-lvm-f... http://www.evanjones.ca/intel-ssd-durability.html
Edit: after some googling:
On Linux, sync is guaranteed only to schedule the dirty blocks for
writing; it can actually take a short time before all the blocks are
finally written. The reboot(8) and halt(8) commands take this into
account by sleeping for a few seconds after calling sync(2).
This page describes sync as found in the fileutils-4.0 package; other
versions may differ slightly.
On Linux, sync is guaranteed only to schedule the dirty blocks for
According to the standard specification (e.g., POSIX.1-2001), sync()
schedules the writes, but may return before the actual writing is done.
However, since version 1.3.20 Linux does actually wait. (This still
does not guarantee data integrity: modern disks have large caches.)
Also, counting on sync() to write everything within two seconds seems problematic as well.
The issue here is storage devices may lie about it[0]. The 2s sleep is problematic, but IIRC devices don't (and have no way to, and would not anyway) report when the data is actually written to permanent storage, so you can't do much besides waiting a bit and hoping for the best.
Which `sync` uses. My comment was probably unclear, but the point I was trying to make is if they're lying to sync they're probably not going to provide other accurate ways to get the information.
It is not a reasonable risk on a normal system, but TFA uses a readonly filesystem (squashfs) so it's not an issue: there's no data to be written.