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@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
