nfs client serious problems under 2.2.20pre8/9

nfs client serious problems under 2.2.20pre8/9

[Ethan Benson]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]


I have encountered a serious problem with nfs under 2.2.20pre8 and
pre9.

after some ammount of time (2 weeks under pre8, only a few hours under
pre9) most/all processes accessing an nfs filesystem go into
unkillable disk sleep, and the kernel starts spewing:

kernel: nfs: task 22509 can't get a request slot

over and over again endlessly.  since processes using the filesystem
are unkillable i am unable to even forcabily umount the problematic
filesystem, seemingly the only way restore order is shutdown -r now :(

the server is an x86 running 2.2.19, knfs, with userland utils
version 0.3.1.  the client is a powerpc running 2.2.20pre8 or pre9,
both exhibit this behavior.  2.2.19 on the client does NOT exhibit
this problem.

note that this seems to mostly get triggered on my daily cronjobs,
which simply tar up /etc to a tarball on the nfs filesystem, its
really not that intensive (/etc is only about 2.6MB or so). i have
other machines doing the same thing without incident (they are
currently running 2.4.9).

the server displays no unusal symtoms or any log entries that would
indicate trouble.

both client and server are using NFSv3.

please CC me any replies as i am not subscribed to l-k.  thanks.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: nfs client serious problems under 2.2.20pre8/9

[VDA]

Tuesday, September 04, 2001, 6:18:49 AM, Ethan Benson <erbenson@alaska.net> wrote:
EB> I have encountered a serious problem with nfs under 2.2.20pre8 and
EB> pre9.
EB> after some ammount of time (2 weeks under pre8, only a few hours under
EB> pre9) most/all processes accessing an nfs filesystem go into
EB> unkillable disk sleep, and the kernel starts spewing:
EB>
EB> kernel: nfs: task 22509 can't get a request slot
EB>
EB> over and over again endlessly.  since processes using the filesystem
EB> are unkillable i am unable to even forcabily umount the problematic
EB> filesystem, seemingly the only way restore order is shutdown -r now :(

Looks like another argument against hard NFS mounts to me.
Does anybody knows why NFS hard mounts exist?
Is there any case when intr mounts is worse than hard ones?
-- 
Best regards,
VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua
http://port.imtp.ilyichevsk.odessa.ua/vda/