On 3/26/21 2:26 AM, Chris Murphy wrote:
If you have 40G of dirty data and your program says "fsync it" you've got 40G of data that has been ordered flushed to stable media. Everything else wanting access is going to come close to stopping. That's the way it works. You don't get to "fsync this very important thing..but oh yeah wait I wanna read a b.s. chrome cache file hold on a sec. Ok thanks, now please continue syncing." That's in effect something that multiqueue NVMe can do. So there's a work around.
Well, there is no reason for fsync to block everything else. The meaning of fsync is that process is telling "I will not proceed until you tell me this file has reached the disk", and that is a hint to the kernel to begin writing with the objective to let the process get unstuck. Indeed fsync doesn't mean "hey, I am in emergency mode, stop everything else because my stuff is important". So a good filesystem on a good kernel will correctly apply priorities, fairness etc. to let other processes do their I/O. You are not irreversibly queueing 40G to the drive, the drive is going to get small operations (e.g. 1000 blocks) and there is a chance for the kernel to insert other I/O in the flow. But there are two issues to consider: 1) there could be huge "irreversible" queues somewhere; this problem is similar to bufferbloat for network packets, but I do not think I/O suffers too much, considering there are no intermediate nodes in the middle 2) there must not be shortcomings in the filesystem code; for example, ext3 ordered mode was flushing everything when asked to flush a 1kB file; I don't know about ext4, I don't know about btrfs In summary: - if a process calls fsync and then complains about having to wait to get unblocked, it is just creating its own problem (are you doing fsync of big things in your UI thread?) - if a process gets heavily delayed because another process is doing fsync the kernel is not doing its job in terms of fairness I can agree that reality may not be ideal, but I don't like this attitude of "dropping the ball" by disabling caching here and there because (provocative paradox) web browser authors are using fsync for bookmarks and cookies DB in the UI thread. NOTE: I know about eatmydata, I've used it sometimes. There is also this nice trick for programs stupidly doing too many fsync: system-nspawn --system-call-filter='~sync:0 fsync:0' Regards. -- Roberto Ragusa mail at robertoragusa.it _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
