> and they're honest about this just being about boot time.
reboot, not boot, boot was already a non-issue after booting into sh and removing most of the services.
The later posts deal with shutdown, mostly by removing sleeps... which are there to wait for lying hardware to finish flushing its caches. So some of TFA's fixes are really recipes for data corruption if you're not using a readonly FS (which TFA is, so it's no problem for his precise use-case).
Yeah, I was reading the bits where they disabled the sleep()s and I couldn't help but wonder how many evil little bugs and device problems those kludges covered up.
No. sync() is the system-wide fsync() so it makes no difference. The issue is that sync() tells the filesystem to flush its caches to storage, the FS tells storage to get everything in permanent storage and the storage device lies its pants off and says everything is stored as soon as it's hit the controller or the write cache.
It's not like the layers above can just go "nuh-uh, tell me when it's actually really written for real", if the storage device is going to lie it's going to lie every time.
The way the SCSI layer is implemented in Linux, fsync() (for that matter O_SYNC I/O) doesn't really flush data to the non-volatile platter on disk. Too much of a performance hit if it did that all the time.
That blog post is from 2005. There was a major rework of how the block layer handles flushes back around 2010 and I'm pretty sure the issue he was having with fsync not being reliable has been resolved.
To go into the details, essentially, its the AHCI-driver(SATA) that handles 2 use-cases differently.
The more common being the case where there is an additional VFS driver between the app attempting sync-I/O and the AHCI driver which simply issues an asynchronous I/O command to the disk and returns immediately. The new data is guaranteed to be on the HDD but NOT guaranteed to be written to the non-volatile platter of the HDD. Data is often still in the HDD internal-cache, waiting to be written to the disk platter.
The 2nd case (very rare) is when the application attempting sync-I/O opens the HDD in raw mode i.e. opens the block device directly(without any VFS layer in between) with O_SYNC. Now following each disk-write, the AHCI driver issues a CMD_FLUSH to ensure that even the HDD cache is immediately flushed to the platter. As this eliminates any chance for NCQ to kick in, the performance drops by an order of magnitude but data-integrity is ensured.
reboot, not boot, boot was already a non-issue after booting into sh and removing most of the services.
The later posts deal with shutdown, mostly by removing sleeps... which are there to wait for lying hardware to finish flushing its caches. So some of TFA's fixes are really recipes for data corruption if you're not using a readonly FS (which TFA is, so it's no problem for his precise use-case).