> On Jul 30, 2026, at 1:04 PM, Stefan Monnier <[email protected]> wrote: > >> I'm getting some weird latency issues with fsync on the RAID disk >> (/home on /dev/md125): (Caveat: I'm doing a file transfer that is >> writing to /home, so I might expect some latency, but nothing >> like this.) >> >> $ for i in {1..5}; do time sync; done 2>&1 | grep real >> real 0m21.647s >> real 0m11.770s >> real 0m5.234s >> real 0m3.023s >> real 0m0.462s > > Why do you expect "nothing like this"? > > I have no idea if your numbers are normal or not, but 21s on a 3-disk > RAID writing at max speed (i.e. 6Gb/s) is 6Gbx21 =~ 16GB. > > So if the file transfer has accumulated 16GB of data in the write queue, > it's perfectly normal for `sync` to take 20s. > And if the file transfer goes at about 400MB/s, you'll have transferred > about 8GB during those 20s, so it stands to reason that the next sync > will still have 8GB to write to disk which will take another 10s, > and then 5s for the next, ...
Good thoughts. And fair enough. The sync output was not the original problem; that was something I was using to try to narrow things down, but I can see how it might be a red herring. The problem originally manifested itself when I was running commands that called the fsync() system call, inducing long I/O delays. For example, running `sudo -e ...` or even `man ...` (because of writing to `lesshst` in home directory). What helped me narrow it down a bit was noticing the `sudo man foo` seemed to have no delay issues (because it wrote to /root, not on RAID), while `man foo` experienced major delays (because it wrote to /home on RAID). I used strace to narrow it down to calls to fsync(). I was using sync to reproduce the issues from the command line. Casey
