NFS woes in 2.5.1-pre8

NFS woes in 2.5.1-pre8

[Russell King]

I'm not sure if this is expected or not, but I'm seeing odd behaviour with
NFS on 2.5.1-pre8:

[root@assabet bin]$vdir ../lib
-rwxr-xr-x    1       51       51   29091 Dec 12  2001 libts-0.0.so.0.0.0
../lib: Input/output error
[root@assabet bin]$uname -a
Linux assabet 2.5.1-pre8 #69 Mon Dec 10 22:21:15 GMT 2001 armv4l unknown
[root@assabet bin]$

Looking at the NFS traffic:

16:27:09.051301 assabet.arm.linux.org.uk.33f11c24 > raistlin.arm.linux.org.uk.nfs: 148 lookup fh Unknown/1 "libts-0.0.so.0" (DF)
16:27:09.061306 raistlin.arm.linux.org.uk.nfs > assabet.arm.linux.org.uk.33f11c24: reply ok 128 lookup fh Unknown/1 (DF)

Admittedly raistlin is running a rather old, obsolete NFS server, which has
up until now worked faultlessly for around 2 years: Universal NFS Server
2.2beta48

Appologies, but I'm not sure how I got it into this state either - last
thing I had done was to overwrite the files in ../lib and bin with new sets
on the NFS server.  The only directory that is suffering is ../lib.
(there's bin and ../include as well, both of which would've had their
files overwritten with later versions).

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: NFS woes in 2.5.1-pre8

[Tyler BIRD]

Search the kernel sources at: http://lxr.linux.no/source/kernel/?v=2.4.13 or 2.4.26, etc
I know the ip addres for each interface are stored somewhere.
They have to be because they are passed down to the net driver inside of  socket buffers ( skb )
as a struct tcphdr *  and they have to be appended to each packet.

Tyler


>>> Russell King <rmk@arm.linux.org.uk> 12/12/01 09:43AM >>>
I'm not sure if this is expected or not, but I'm seeing odd behaviour with
NFS on 2.5.1-pre8:

[root@assabet bin]$vdir ../lib
-rwxr-xr-x    1       51       51   29091 Dec 12  2001 libts-0.0.so.0.0.0
../lib: Input/output error
[root@assabet bin]$uname -a
Linux assabet 2.5.1-pre8 #69 Mon Dec 10 22:21:15 GMT 2001 armv4l unknown
[root@assabet bin]$

Looking at the NFS traffic:

16:27:09.051301 assabet.arm.linux.org.uk.33f11c24 > raistlin.arm.linux.org.uk.nfs: 148 lookup fh Unknown/1 "libts-0.0.so.0" (DF)
16:27:09.061306 raistlin.arm.linux.org.uk.nfs > assabet.arm.linux.org.uk.33f11c24: reply ok 128 lookup fh Unknown/1 (DF)

Admittedly raistlin is running a rather old, obsolete NFS server, which has
up until now worked faultlessly for around 2 years: Universal NFS Server
2.2beta48

Appologies, but I'm not sure how I got it into this state either - last
thing I had done was to overwrite the files in ../lib and bin with new sets
on the NFS server.  The only directory that is suffering is ../lib.
(there's bin and ../include as well, both of which would've had their
files overwritten with later versions).

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org 
More majordomo info at  http://vger.kernel.org/majordomo-info.html 
Please read the FAQ at  http://www.tux.org/lkml/

Re: NFS woes in 2.5.1-pre8

[Russell King]

On Wed, Dec 12, 2001 at 10:22:04AM -0700, Tyler BIRD wrote:
> Search the kernel sources at: http://lxr.linux.no/source/kernel/?v=2.4.13 or 2.4.26, etc
> I know the ip addres for each interface are stored somewhere.
> They have to be because they are passed down to the net driver inside of  socket buffers ( skb )
> as a struct tcphdr *  and they have to be appended to each packet.

Sorry, I don't see what this has to do with my NFS problem.

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: NFS woes in 2.5.1-pre8

[Trond Myklebust]

>>>>> " " == Russell King <rmk@arm.linux.org.uk> writes:

     > I'm not sure if this is expected or not, but I'm seeing odd
     > behaviour with NFS on 2.5.1-pre8:

     > [root@assabet bin]$vdir ../lib -rwxr-xr-x 1 51 51 29091 Dec 12
     > 2001 libts-0.0.so.0.0.0 ../lib: Input/output error
<snip>
     > Admittedly raistlin is running a rather old, obsolete NFS
     > server, which has up until now worked faultlessly for around 2
     > years: Universal NFS Server 2.2beta48

     > Appologies, but I'm not sure how I got it into this state
     > either - last thing I had done was to overwrite the files in
     > ../lib and bin with new sets on the NFS server.  The only
     > directory that is suffering is ../lib.  (there's bin and
     > ../include as well, both of which would've had their files
     > overwritten with later versions).

There are (as of yet) no changes to the NFS client in 2.5.x.

Do you have any idea which syscall the above EIO is coming from? From
your tcpdump, it didn't appear to be coming from the server, and the
file attributes are getting displayed...

Cheers,
   Trond

Re: NFS woes in 2.5.1-pre8

[Russell King]

On Wed, Dec 12, 2001 at 10:02:01PM +0100, Trond Myklebust wrote:
> There are (as of yet) no changes to the NFS client in 2.5.x.
> 
> Do you have any idea which syscall the above EIO is coming from? From
> your tcpdump, it didn't appear to be coming from the server, and the
> file attributes are getting displayed...

Ok, I've just seen it again.  Here's the call that's failing:

lstat("../lib/libts_variance-0.0.so.0", 0xbffffb98) = -1 EIO (Input/output error)

It seems that sometimes I can provoke it 4 or more times in a row, other
times no matter how hard I try, I can't.  "4 times in a row" here means
umounting and then remounting the export on the assabet.

As I mentioned in my last (private) mail, the setup was slightly different
from my first description.

flint (nfs client) is responsible for writing these files onto the NFS server
(raistlin), and the programs are run on assabet (nfs client).

flint
-----
  kernel 2.2.18-cdhs (raid)

  mount indicates:
  raistlin:/usr/src on /net/raistlin/src type nfs (rw,rsize=4096,wsize=4096,addr=192.168.0.3)

raistlin
--------
  kernel 2.4.16
  universal NFS server 2.2beta48

  raistlin's exports file looks similar to the following:

  /usr/src	flint(rw,no_root_squash)
  /usr/src/v2.5	assabet(ro)

assabet
-------
  kernel 2.5.1-pre10

  mount indicates:
  raistlin:/usr/src/v2.5 on /usr/src/v2.5 type nfs (ro,nolock,addr=192.168.0.3)

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: NFS woes in 2.5.1-pre8

[Trond Myklebust]

>>>>> " " == Russell King <rmk@arm.linux.org.uk> writes:

     > lstat("../lib/libts_variance-0.0.so.0", 0xbffffb98) = -1 EIO
     > (Input/output error)

Ah.. Do you also get the error

   nfs_refresh_inode: inode number mismatch
   expected (blah), got (blech)

in your syslog? If so it's because the unfsd is reusing filehandles.

Cheers,
   Trond