Hello,
I'm fighting for a while with using NFSv4 provided by HP-UX 11.31 (ONCplus
B.11.31.04 (ONC+ 2.3)) on a SLES10 SP1 (x86_64) client. HP's NFS is basically that
from Sun. The problems are:
Mounting the filesystems as NFSv3 causes no problems at all, using NFSv4 makes
every file open() attempt to hang hard. I must "kill -9" the processes. Even
"umount -vat nfs4" hangs on umount().
The only messages I get when trying an open is
kernel: Error: state recovery failed on NFSv4 server 192.168.0.20 with error 5
For umount the error message seems to be
rksapas08 kernel: Error: state recovery failed on NFSv4 server 192.168.0.20 with
error 2
On the HP-UX server I see messages like these, but I'm unsure whether they are
related to Linux:
vmunix: NOTICE: sec_clnt_geth: unknown authflavor 2037596260, trying AUTH_NONE
vmunix: NOTICE: sec_clnt_geth: unknown authflavor 10, trying AUTH_NONE
When HP-UX uses NFSv4 (same software as quoted above), no such problems appear.
The server is a four-core Itanium2 (IA64) machine.
I'd appreciate any help towards understanding the error messages and debugging the
problem.
Regards,
Ulrich
P.S. Not subscribed, so please CC:
On Thu, 28 Aug 2008, Ulrich Windl wrote:
> I'm fighting for a while with using NFSv4 provided by HP-UX 11.31 (ONCplus
> B.11.31.04 (ONC+ 2.3)) on a SLES10 SP1 (x86_64) client. HP's NFS is basically that
> from Sun. The problems are:
[ ... ]
> Mounting the filesystems as NFSv3 causes no problems at all, using NFSv4 makes
> every file open() attempt to hang hard. I must "kill -9" the processes. Even
> "umount -vat nfs4" hangs on umount().
Sorry, but this mailinglist would be appropriate only if this happens
still with current vanilla kernel.
Otherwise, you should report this problem to your vendor (Novell bugzilla
in this case).
--
Jiri Kosina
SUSE Labs
On 28 Aug 2008 at 13:37, Jiri Kosina wrote:
> On Thu, 28 Aug 2008, Ulrich Windl wrote:
>
> > I'm fighting for a while with using NFSv4 provided by HP-UX 11.31 (ONCplus
> > B.11.31.04 (ONC+ 2.3)) on a SLES10 SP1 (x86_64) client. HP's NFS is basically that
> > from Sun. The problems are:
> [ ... ]
> > Mounting the filesystems as NFSv3 causes no problems at all, using NFSv4 makes
> > every file open() attempt to hang hard. I must "kill -9" the processes. Even
> > "umount -vat nfs4" hangs on umount().
>
> Sorry, but this mailinglist would be appropriate only if this happens
> still with current vanilla kernel.
>
> Otherwise, you should report this problem to your vendor (Novell bugzilla
> in this case).
Hi!
(ingoring the fact your opinion may be influenced by SUSE/Novell)
Are you saying that SUSE/Novell added bugs regarding NFS4 that are not present in
the vanilla kernel, or are you saying that the vanilla kernel may have fixed NFSv4
bugs that SUSE/Novell did not fix? Why shouldn't anybody be interested in the fact
that there are problems?
Regards,
Ulrich
On Thu, 28 Aug 2008, Ulrich Windl wrote:
> > > Mounting the filesystems as NFSv3 causes no problems at all, using NFSv4 makes
> > > every file open() attempt to hang hard. I must "kill -9" the processes. Even
> > > "umount -vat nfs4" hangs on umount().
> > Sorry, but this mailinglist would be appropriate only if this happens
> > still with current vanilla kernel.
> > Otherwise, you should report this problem to your vendor (Novell bugzilla
> > in this case).
> (ingoring the fact your opinion may be influenced by SUSE/Novell)
In what sense? Do you think I am trying to direct as much bugs as possible
our way? :)
> Are you saying that SUSE/Novell added bugs regarding NFS4 that are not
> present in the vanilla kernel, or are you saying that the vanilla kernel
> may have fixed NFSv4 bugs that SUSE/Novell did not fix? Why shouldn't
> anybody be interested in the fact that there are problems?
linux-kernel malinglist is focused on vanilla kernel development. i.e. all
the bugs that are present in the current version of the code are very
welcome to be reported here.
SLES10 is based on 2.6.16 kernel, which has little interest for vanilla
kernel developers. The bug you might be seeing could be caused by some
SLES-specific patch (which is not probable, there are not many out-of-tree
patches really), could have been fixed already a long time ago in upstream
kernel version, or could be still present. Upstream kernel developers are
interested only in the latest case. Otherwise, it's up to your distro
kernel vendor to provide support.
--
Jiri Kosina
SUSE Labs