I'm asking here before reporting it to TUV just in case I'm doing 
something really stupid.

Just for some variety we just discovered a different NFS problem with the 
new SL5 kernels - with the NFS server stuff this time.

Having upgraded a box to 2.6.18-53.1.4.el5 (either x86 or x86_64), older 
Linux boxes (e.g. SL3 boxes running 2.4.21-53.EL) mounting from the server 
start reporting 'EIO' errors when they tries to get some kinds of info. 
e.g.

$ mkdir /mnt/testing
$ mount zex:/local/scratch/ /mnt/testing/
$ ls -al /mnt/testing/public/test
ls: /mnt/testing/public/test: Input/output error
-rw-r--r--    1 jp107    other         367 Dec 18 16:24 /mnt/testing/public/test

After some tracking down (based on the logs on the server and tracing the 
traffic) it seems that this is a problem with the nfs acl code and 
mounting noacl fixes it (at least that is a short term fix)...

$ umount /mnt/testing/
$ mount -o noacl zex:/local/scratch/ /mnt/testing/
$ ls -al /mnt/testing/public/test
-rw-r--r--    1 jp107    other         367 Dec 18 16:24 /mnt/testing/public/test

Not that we use acls much but this regression seems wrong.

Now it seems NOT to affect clients running newer (2.6) kernels so SL4/SL5 
clients are not affected by this - though it might just be silently 
falling back to not supporting ACLs on there...

I found a brief thread discussing what seems to be the same underlying 
problem (with 2.6.19 kernels) on the kernel mailing list from back in 
January:

   http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-01/msg03478.html

I'm currently building a kernel with the suggested patch (from Neil Brown) 
to check if that fixes it.

Without that patch it seems to not fill in the nfsd_acl_versions[vers] 
fields so probably doesn't handle ACLs at all as far as I can follow.

Does anyone else see this behaviour (or are we the only ones left using 
NFS from such old systems)?

-- 
Jon Peatfield,  Computer Officer,  DAMTP,  University of Cambridge
Mail:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/