On 12/21/19 8:28 PM, Ken Moffat via blfs-support wrote:
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
All though my "systems" are a bit different from yours as I don't use
nfs ( i use sshfs to mount network filesystems locally
)......................
I am using kernel version 5.4.1 on a amd64 desktop machine and the same
network hardware/firmware (as far as I can tell) as Ken is using. I
have git repos on a networked raspberry pi2 running LFS-8.4.
All git clone, push, and pull from the network raspberry pi to the
desktop are without any network slowdown. I store all the source
tarballs in a git repo for every version of LFS that I have worked
on/built. cloning that repo from the raspberry pi2 to the desktop amd64
works well without slowdown. The source tarball git repo is very large.
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
