https://bugzilla.kernel.org/show_bug.cgi?id=214873 Jens Axboe (axboe@xxxxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |axboe@xxxxxxxxx --- Comment #7 from Jens Axboe (axboe@xxxxxxxxx) --- This is still mixing up multiple things. There are two things to consider here: 1) The dirty page cache for the file/device. This is what the kernel knows about, and fsync will flush all of it. 2) The device side potential write back cache. The kernel has no knowledge of the state of this. The kernel will issue a synchronize cache command for the device, upon which the device should ensure that all previously acked data is now on stable storage (eg the cache is clean). The kernel will ensure that _all_ dirty cache is flushed out to the device, and then it will issue a flush command. That's all the kernel can do, and it will not leave dirty data unwritten for that mapping when fsync(2) is invoked. That's outside of errors that can happen, for which fsync(2) will return an error. There's no issue here, outside of the potential buggy device case. For that case, the kernel still does what it's supposed to, which is flush all dirty kernel cache to the device. If the device is buggy and doesn't commit it to stable storage when a synchronize cache command is issued, the kernel has no knowledge of this nor is there anything it can do about it. There's no early return _unless_ the device is buggy! The man page clearly states that the call blocks until the device has told you that the data is stable. If the device violates the storage standards it belongs to, then you are likely screwed in more ways than just this one. Please close this one. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
