On 7/27/26 7:48 AM, Manuel Giraud wrote:
Hi,
Everyday around noon, I'm updating /usr/src, /usr/xenocara and
/usr/ports with a "cvs up" from the mirror:
[email protected]:/cvs
This update takes up to one hour but more worrying is that in the
meantime, the machine is barely usable. I guess that this is mostly due
to IO but I don't know how to debug this.
you seem to be working hard to avoid showing us the info we need: dmesg.
EXACT command line might be interesting.
I just happened to have reason to pull a cvs checkout to a moderately
potent machine from a mirror about 400km away from me, and around a 30ms
ping time. This was all just src/.
Checkout took less than four minutes.
update (granted, nothing to update) took less than a minute.
cvs -q update -Pd took about the same amount of time, a hair faster, not
sure if that was less console I/O or just more stuff in cache.
This was to a cheap SSD.
This machine also happened to have a spinny disk in it and a chunk of
free space, so...tried against that:
checkout: under 20 minutes
update: under six minutes.
Machine was fully responsive. Standard mount options.
Since YOUR machine is responding poorly, I'm pretty sure the problem
is on your end. Slow remote server or slow connectivity should have
you wallowing in spare processor and disk I/O. The remote machine
is sending you everything you can handle, but you are having trouble
handling it.
so...either you have horribly broken hardware, using pciide(4), wdc(4),
or USB or a CF or SD card as storage, or SOMETHING similar...for
unknown reasons, your disk subsystem is very unhappy with lots of
little files. One thing I have seen cause problems like this more
than once is a failing hard disk -- retries ultimately succeed, but
it takes a LOT of retries.
Nick.
