Messages in this thread | | | From | Stephan von Krawczynski <> | Date | Mon, 11 Mar 2002 01:18:48 +0100 | Subject | Re: BUG REPORT: kernel nfs between 2.4.19-pre2 (server) and 2.2.21-pre3 (client) |
| |
> >>>>> " " == Stephan von Krawczynski <skraw@ithnet.com> writes: > > > Hello all, I just upgraded a host from 2.2.19 to 2.2.21-pre3 > > and discovered a problem with kernel nfs. Setup is this: > > > knfs-server is 2.4.19-pre2 knfs-client is 2.2.21-pre3 > > > First mount some fs (mountpoint /backup). Then go and mount > > some other fs from the same server (mountpoint /mnt), do some > > i/o on the latter and umount it again. Now try to access > > /backup. You see: > > 1) /backup (as a fs) vanished, you get a stale nfs handle. > > 2) umount /backup; mount /backup does not work. client tells > > "permission denied". server tells "rpc.mountd: getfh failed: > > Operation not permitted" > > By 'some fs' do you mean ext2? > > Not all filesystems work well with knfsd when things start to drop out > of the (d|i)caches. In particular things like /backup == VFAT might > give the above behaviour, since VFAT does not know how to map the NFS > file handles into on-disk inodes.
Sorry Trond,
this is a weak try of an explanation. All involved fs types are reiserfs. The problem occurs reproducably only after (and including) 2.2.20 and above and _not_ in 2.2.19. There must be some problem. Though I do not know whether the problem is on the client side, or simply produced by this client side and effectively located on 2.4.18 server, I really can't tell. But giving me something to try might clear the picture.
Any hints?
Stephan
- 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/
| |