https://bugzilla.kernel.org/show_bug.cgi?id=214873 --- Comment #8 from sworddragon2@xxxxxxxxx --- (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.
