On Sat, Dec 21, 2019 at 06:10:22PM -0600, Bruce Dubbs via blfs-support wrote:
> On 12/21/19 3:29 PM, Ken Moffat via blfs-support wrote:
> > Anybody else seeing periodic "stalls" in networking with 5.4 kernels
> > and the r8169 driver ? My current feeling is that a lot of network
> > and other changes got into 5.4 because it is the next LTS kernel,
> > and on r8169 (which apparently has a bad reputation for some people)
> > some variants might be be very iffy (although fine in 5.2 and
> > earlier 5.3.stable).
>
> I can't really say anything about the 5.2 or 5.4 kernels. I'm still on
> lfs-9.0 on my development system. However, I've always had some speed
> issues with nfs. If I try to do a tar -xf on the nfs mount, it is very
> slow. If I try to do an rm -r on a moderate sized directory tree, it is
> very slow.
>
I've seen slow untarring over nfs in the past, particularly on my
haswell (which seems not to have problems with the network in 5.4),
but it was a while ago and I think it eventually got resolved on one
of the point releases.
More generally, there can be a delay in getting the file (or in
getting options for name completion after typing the first few
characters), particularly if it comes from a rotating drive which is
allowed to slow down. So yes, for timing installing the data for
texlive, or for biber, I now copy to /tmp before extracting.
But what I've been seeing in the last 2 or 3 days is that even
copying a small file will from time to time have a pause of several
seconds.
> What I do is extract the tarball from the nfs location to a local disk and
> that is quite fast. Writing to a log file on the nfs directory or running a
> script located there seems to run at an appropriate speed.
>
> My thought is that doing a lot of disk operations is slow, but
> open-read/write-close on a few files like a script or log or tarball works
> at relatively full speed.
>
> -- Bruce
Seems reasonable. My scripts are on nfs, so when a stall happens
after a fresh start, the 'driver' script gives some initial output
(e.g. settings for -j in make, CFLAGS), mentions the client script
it will invoke, then waits some (or many) seconds before reporting
the directory name (it identifies the type of tarball - not strictly
necessary nowadays - and then runs tar -tvf | head -n1 to find out
the directory name). Normally, for most tarballs that only takes a
second or so because my /sources is on SSD.
I see that one of the other machines has a 5.4.1 kernel on its 9.0
system, with the nic firmware. I'll take a look at that either
tomorrow or else in the next few days, to see if it also has the
problem. But as I said, sometimes things seem fine, then a bit
later there are lots of problems.
ĸen
--
We've all got both light and dark inside of us.
What matters is the part we choose to act on.
-- Sirius Black
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
