Re: Disk I/O slowness

> On Jul 30, 2026, at 1:04=E2=80=AFPM, Stefan Monnier =
<[email protected]> wrote:
>=20
>> 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.)
>>=20
>> $ 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
>=20
> Why do you expect "nothing like this"?
>=20
> 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 =3D~ 16GB.
>=20
> 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=