[PATCH 2.4.19pre8][RFC] remove-NFS-close-to-open from VFS (was Re: [PATCHSET] 2.4.19-pre8-jp12)

From: Jörg Prante (joergprante@gmx.de)
Date: Thu May 16 2002 - 16:40:19 EST


Hi!

Robinson Maureira Castillo <rmaureira@alumno.inacap.cl> wrote:
> On Thu, 16 May 2002, Tomas Szepe wrote:
> > > But the worst problem for is supermount:
> > > # mount -t supermount -o dev=/dev/cdrom none /mnt/cdrom
> > > # ls -l /mnt/cdrom
> > > ls: .: Stale NFS handle (~or something similar)
> > > [...] (and it lists the file)
> >
> > Hmmm.. I've been seeing this problem in the latest -ac kernels too.
> >
> > Basically, a while after mounting the CD a ls on any subdir of the
> > mount will complain about a 'stale NFS handle' and the device has
> > to be remounted.
> >
> > T.
>
> I'm getting the same with ftpfs, both in jp11 and jp12. Remounting doesn't
> change a thing, it just shows me the root tree, I can cd into directories
> if I know the name, but all I got is those nice 'stale NFS handle' as a
> response from ls

I traced it down. The trouble exists since 2.4.19-pre4. Trond Myklebust
touched the VFS in order to send dentry revalidation events to NFS.

http://www.geocrawler.com/archives/3/789/2002/3/100/8078826/

But Trond's patch conflicts with almost all non-standard virtual or remote
mount file systems (supermount, cdfs, ftpfs, and maybe autofs). I don't know
if the cdfs oops I observed now for a while is related.

Is it possible to leave the VFS layer untouched? Or restrict the dentry
revalidation to NFS and let other remote file systems coexist, i.e. without
revalidation calls?

Or is it recommended to write fixes for the file systems stated above,
because they now have wrong assumptions about the VFS behavior?

Anyway, while these questions arise, I request to remove Trond's patch since
the patch changes too much for 2.4 stable kernel series.

Attached is a revert patch against 2.4.19-pre8 for Marcelo.

Thanks

Jörg



-
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/



This archive was generated by hypermail 2b29 : Thu May 23 2002 - 22:00:12 EST