[Bug 214873] man 2 fsync implies possibility to return early

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=214873

Jens Axboe (axboe@kernel.dk) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |axboe@kernel.dk

--- Comment #7 from Jens Axboe (axboe@kernel.dk) ---
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.