 | | | getxattr() problem with NFS client? | getxattr() problem with NFS client? 2005-01-10 - By Garrick Staples
Back
On Mon, Jan 10, 2005 at 05:02:42PM -0500, Tom Sightler alleged:
> On Mon, 2005-01-10 at 13:37 -0800, Garrick Staples wrote:
>
> > So far, I have two workarounds, loading the nfs module with
> > nfs3_acl_max_entries=0 or mounting with nfsvers=2. The redhat docs mention
a
> > mount option of "no_acl" but that option doesn't actually exist.
>
>
> My guess is your seeing the infamous NFS bug. Do you have to go all the
> way to nfs3_acl_max_entries = 0? What about nfs3_acl_max_entries=256
> (the default is 1024 which requires an order 2 allocation while setting
> of 256 supposedly only requires a order 0 allocation)? That should lower
> the threshold enough to workaround the bug while still allowing for
> ACL's to work (assuming you need them).
I'm pretty sure this is a different problem (I bumped up repeatedly against the
original problem that you are talking about).
1) max_entries=256 doesn't fix the problem.
2) It only happens with samfs filesystems. Normal UFS filesystems don't have
this problem.
3) I've now seen in tcpdump that the server is actually returning EIO...
14:26:29.813760 hpcjr-master-l.usc.edu.3101723527 > samfs2.usc.edu.nfs: 144
getattr [|nfs] (DF) (ttl 64, id 6989, len 184)
14:26:29.814125 samfs2.usc.edu.nfs > hpcjr-master-l.usc.edu.3101723527: reply
ok 120 getattr ERROR: Input/output error (DF) (ttl 64, id 6856, len 160)
Obviously we can just chalk this up to a samfs problem, except that Solaris
clients aren't having any problems.
--
Garrick Staples, Linux/HPCC Administrator
University of Southern California
--
Taroon-list mailing list
Taroon-list@(protected)
http://www.redhat.com/mailman/listinfo/taroon-list
Earn $52 per hosting referral at Lunarpages.
|
|
|