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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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 <[email protected]> 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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
>>>>> " " == Russell King <[email protected]> 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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
>>>>> " " == Russell King <[email protected]> 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