Re: Disk I/O slowness

[Casey Deccio <casey@deccio.net>]

> On Jul 30, 2026, at 1:04 PM, Stefan Monnier <monnier@iro.umontreal.ca> 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