3 ms·

Hmmm. For hard disks, a call to fsync could be sufficient instead of the sleeps, no?

by leoh 13y ago

mro 13y ago
No: http://brad.livejournal.com/2116715.html http://brad.livejournal.com/2116715.html
- magila 13y ago
  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.
  - cvs268 13y ago
    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.
cvs268 13y ago
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. http://thecodeartist.blogspot.com/2012/08/hdd-filesystems-osync.html http://thecodeartist.blogspot.com/2012/08/hdd-filesystems-os...
masklinn 13y ago
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.

Hmmm. For hard disks, a call to fsync could be sufficient instead of the sleeps, no?

by leoh 13y ago

Hmmm. For hard disks, a call to fsync could be sufficient instead of the sleeps, no?

mro 13y ago

No: http://brad.livejournal.com/2116715.html http://brad.livejournal.com/2116715.html

magila 13y ago
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.
- cvs268 13y ago
  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.

cvs268 13y ago

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. http://thecodeartist.blogspot.com/2012/08/hdd-filesystems-osync.html http://thecodeartist.blogspot.com/2012/08/hdd-filesystems-os...

masklinn 13y ago

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.