Date: Sat, 20 Sep 1997 18:25:42 +0300 (EEST) From: Heikki Suonsivu <hsu@mail.clinet.fi> To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: kern/4588: NFS access locks up Message-ID: <199709201525.SAA23098@zetor.clinet.fi> Resent-Message-ID: <199709201530.IAA10248@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 4588
>Category: kern
>Synopsis: NFS access locks up
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-bugs
>State: open
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sat Sep 20 08:30:01 PDT 1997
>Last-Modified:
>Originator: Heikki Suonsivu
>Organization:
Clinet, Espoo, Finland
>Release: FreeBSD 2.2-STABLE i386
>Environment:
FreeBSD-2.2, mostly late STABLE kernels but this seems to have been around
for some time. These are usually SCSI, either NCR or 2940 configurations,
with 64M to 128M of memory, Pentiums from 133MHz and up.
>Description:
NFS clients deadlock on something, directories or files. Nothing kills the
processes, not even kill -9. For some reason the files are almost always
files which are WWW server related, but not necessarily on WWW server's
disks. So it is access logs and users WWW directories which lock up. It
could be either the directory or one of the files in the directory which go
into this state. I think the reason for WWW stuff to lock up is related to
usage pattern, as we have seen the problem with other files, just it has
been rare.
Usually rebooting the client fixes it temporarily, but some cases it won't.
In particular if it failed when user was using microsoft frontpage to
update the contents of the directory, it usually locks the directory up
again as soon as he tries to update the pages after the reboot.
It seems to be the client which is the problem, as while some clients lock
up reading the file/directory I can still see it from other nfs clients.
ps axuwwwl:
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
hsu 9170 0.0 0.3 228 208 p0 D+ 5:27PM 0:00.03 less access_log. 105 9170 20972 1 -4 0 228 208 nfsvin D+ p0 0:00.03 less access_log.874368000
hsu 19077 0.0 0.1 196 68 p7 R+ 6:08PM 0:00.01 egrep (less|USER 105 19077 18879 3 28 0 196 68 - R+ p7 0:00.01 egrep (less|USER)
fstat:
hsu less 9170 wd /m/varasto/usr 21696 drwxr-xr-x 512 r
hsu less 9170 text /usr 9064 -r-xr-xr-x 73728 r
hsu less 9170 0 / 4189 crw--w---- ttyp0 rw
hsu less 9170 1 / 4189 crw--w---- ttyp0 rw
hsu less 9170 2 / 4189 crw--w---- ttyp0 rw
hsu less 9170 3 / 3993 crw-rw-rw- tty r
I cannot get sensible tcpdump unless I know how to look for a specific
thing, the nfs server is very busy. Any ideas what to look for ?
>How-To-Repeat:
Busy clients seem to exhibit this more frequently.
>Fix:
--
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@clinet.fi
mobile +358-40-5519679 work +358-9-43542270 fax -4555276
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709201525.SAA23098>