Hi
I am running unfsd 0.9.16 on a linux 2.6 machine. I notice that from a
client machine while reading a file (say XYZ) the NFS client does GETATTR
using a file handle corresponding to that file, and unfsd after processing
that request initiates a LOOKUP operation for another file in the same
directory. ? I would have expected the unfsd to do a LOOKUP for XYZ, but
instead it does LOOKUP for another file in the same directory. Perhaps the
unfsd is mapping that file handle to a different file name from what the
client thinks is the file name?
Murali
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
It's not a LOOKUP operation in the NFS sense, actually the FUSE module that
is handling the operation reports it as a lookup (the unfsd backend call
ends up being handled by a FUSE server that i am developing). What actually
happens on the FUSE side is a operation (called getattr, not to be confused
with the NFS getattr) with a path name and the path name happens to be a
altogether different file name. I noticed in the unfsd code that the unfsd
is maintaining a file handle cache, and also issues backend operations based
on the path name in that cache, could there be a stale entry in that cache?
Is there a way to turn off this file handle caching in unfsd? At this point
i am not sure whether FUSE may be causing this behaviour or not.
Thx,
Murali
On 11/22/06, Peter Astrand <[email protected]> wrote:
>
> On Tue, 21 Nov 2006, Murali Bashyam wrote:
>
> > I am running unfsd 0.9.16 on a linux 2.6 machine. I notice that from a
> > client machine while reading a file (say XYZ) the NFS client does
> GETATTR
> > using a file handle corresponding to that file, and unfsd after
> processing
> > that request initiates a LOOKUP operation for another file in the same
> > directory. ?
>
> You are saying that unfsd initiates a LOOKUP operation on itself? That
> doesn't make sense. I suggest that you give us access to a tcp dump,
> Wireshark screenshot or something like that.
>
> Regards,
> --
> Peter ?strand ThinLinc Chief Developer
> Cendio AB http://www.cendio.se
> Teknikringen 3
> 583 30 Link?ping Phone: +46-13-21 46 00
>
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On 11/22/06, Peter Astrand <[email protected]> wrote:
>
>
> > It's not a LOOKUP operation in the NFS sense, actually the FUSE module
> that
> > is handling the operation reports it as a lookup (the unfsd backend call
> > ends up being handled by a FUSE server that i am developing). What
> actually
> > happens on the FUSE side is a operation (called getattr, not to be
> confused
> > with the NFS getattr) with a path name and the path name happens to be a
> > altogether different file name.
>
> The FUSE getattr is probably the result of unfsd doing a normal stat().
> This is expected: When unfsd is "decomposing" a file handle into a path,
> it stat:s every file in the target directory (actually, plausible
> directories), until it finds a file with the correct st_dev and st_ino.
>
>
> > I noticed in the unfsd code that the unfsd is maintaining a file handle
> > cache, and also issues backend operations based on the path name in that
> > cache, could there be a stale entry in that cache? Is there a way to
> > turn off this file handle caching in unfsd? At this point i am not sure
> > whether FUSE may be causing this behaviour or not.
>
> If you turn off the file handle cache, the number of stat()s will
> increase.
So while performing the stat call, it has to map the file handle which came
in the GETATTR NFS request to a file name, correct? My question was whether
it is possible that the mapping can become stale, if that mapping is
cached.
Murali
Regards,
> --
> Peter ?strand ThinLinc Chief Developer
> Cendio AB http://www.cendio.se
> Teknikringen 3
> 583 30 Link?ping Phone: +46-13-21 46 00
>
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs