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

[bugzilla-daemon@bugzilla.kernel.org]

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

--- Comment #8 from sworddragon2@gmail.com ---
(In reply to Jens Axboe from comment #7)
> 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 is pretty clear and now I would say the mentioned sentence should be
indeed being updated but...


(In reply to Jens Axboe from comment #7)
> The man page clearly states that the
> call blocks until the device has told you that the data is stable.

This would probably go better with an example: Userspace requests 600 MiB to be
written to an external storage device. fsync(2) has been called, 500 MiB have
been sent to the storage device and 100 MiB are still in the dirty kernel
cached data. At this point due to a slight firmware-bug the device falsely
signals the transfer has been completed (but might not reject further received
data). The referenced sentence in the manpage strictly claims fsync(2) returns
here despite the kernel still having 100 MiB dirty kernel cached data while the
part before claims the 100 MiB would also have been flushed - that is the
conflict I'm claiming about here.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.