Stability of NFSv4

[Josh Lange]

I have tried using nfsv3. I get "permission denied" when I try to mount any
shares.

I can successfully mount nfsv4 through the automounter, or:
mount -t nfs4 -o sec=krb5 csl2.csc.calpoly.edu:/u1/home /mnt/test

Trying this fails with a permission denied error:
mount -t nfs -o sec=krb5 csl2.csc.calpoly.edu:/u1/home /mnt/test
(or through /sbin/mount.nfs)

So, I pulled out wireshark:
http://www.csc.calpoly.edu/~jhlange/failedkrb5.dmp . The client isn't even
attempting to use kerberos when contacting mountd, and mountd returns an
error.

The client is Fedora 7:
Kernel: 2.6.22.4-65.fc7 i686
nfs-utils: nfs-utils-1.1.0-3.fc7

Is this just an oddity in the fedora nfs-utils package?

Josh

On 9/29/07, Burlyga, Alex <Alex.Burlyga at netapp.com> wrote:
>
>  if the only requirement for you is kerberos, then nfsv3 works just fine
> using that
> as authentication mechanism. However, you might need to pull in latest nfs-utils
>
> for it to be stable.
>
> Alex.
>
>  ------------------------------
> *From:* Josh Lange [mailto:jhlange at calpoly.edu]
> *Sent:* Saturday, September 29, 2007 12:47 AM
> *To:* nfsv4 at linux-nfs.org
> *Subject:* Stability of NFSv4
>
> I'm currently a student at Cal Poly, San Luis Obispo. In addition to that,
> I work in the computer science department. The full time sysadmins, and
> myself manage ~200 lab machines, and several shell servers for student and
> faculty use.
>
> Since students have physical access to the lab machines (subnets/hosts),
> we have been using NFSv4 with kerberos (plain krb5) to serve up files.
> Another thing to mention is that these machines can/are randomly turned off,
> and about everything else one could expect from publicly accessible systems.
>
>
> Over the past summer, we had a major overhaul of all of our servers.
> Mainly, to reduce administration time, we moved a bunch of our servers off
> of Solaris, this included our file servers (some of which have radically
> different hardware, all are having problems. They are now running CentOS 5,
> x86_64 kernel v2.6.18.1). Everything went great until classes started.
>
> Panics started rolling in (~once every 1-2 days).  I can remember a few
> times when complaints about a kernel thread lockup scrolled by the screen,
> right before we get the full kernel panic trace. sunrpc seems to be on the
> top of the call stack in the panic trace most of the time, we think we may
> be hitting this bug:
> http://www.linux-nfs.org/Linux-2.6.x/2.6.22/linux-2.6.22-038-fix_reconnect_deadlock.dif
> (We have not enabled kdump on the server yet, but that's not the point of
> this mailing)
>
> RedHat seems to be marketing NFSv4 on their Enterprise platform (
> http://www.redhat.com/rhel/server/details/#deployments ), without any
> mention about how it is still considered a experimental feature in the linux
> kernel. Other mail threads seem to have said that NFSv4 was only ready for
> early adopters, but I can't find anything more recent than ~March 2005 that
> makes a statement either way.
>
> The bottom line is: We need a stable NFS+kerberos platform that can handle
> serving files to relatively erratic clients. We want to use linux, but our
> recent issues make us weary about the stability of NFSv4 on linux.
>
> Is there anything that we should do to make our NFS servers more stable?
> Is linux nfs ready for this type of day to day abuse?
>
>
> Thank you for any advice you guys can give us,
> Josh Lange
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/nfsv4/attachments/20071003/722dad78/attachment.htm