From: "Murali Bashyam" Subject: Re: unfsd strange behaviour ? Date: Wed, 22 Nov 2006 10:42:41 -0800 Message-ID: <9c8209a10611221042v6d669d3tbabf405022f0efcb@mail.gmail.com> References: <9c8209a10611212358o75127f4qd433e37c32fefc29@mail.gmail.com> <9c8209a10611220835h40af88fdpdb4c36327e674235@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0121585929==" Cc: nfs@lists.sourceforge.net Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1Gmx3Y-0005g4-Pm for nfs@lists.sourceforge.net; Wed, 22 Nov 2006 10:42:49 -0800 Received: from nf-out-0910.google.com ([64.233.182.187]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1Gmx3Y-0006hB-Cd for nfs@lists.sourceforge.net; Wed, 22 Nov 2006 10:42:50 -0800 Received: by nf-out-0910.google.com with SMTP id c31so967043nfb for ; Wed, 22 Nov 2006 10:42:42 -0800 (PST) To: "Peter Astrand" In-Reply-To: List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net --===============0121585929== Content-Type: multipart/alternative; boundary="----=_Part_12431_6816516.1164220961797" ------=_Part_12431_6816516.1164220961797 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 11/22/06, Peter Astrand 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 cal= l > > 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 tha= t > > 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 =C5strand ThinLinc Chief Developer > Cendio AB http://www.cendio.se > Teknikringen 3 > 583 30 Link=F6ping Phone: +46-13-21 46 00 > ------=_Part_12431_6816516.1164220961797 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 11/22/06, Peter Astrand <astrand= @cendio.se> wrote:

> It's not a LOOKUP operation in the NFS sense, actually the FUSE mo= dule that
> is handling the operation reports it as a lookup (the unf= sd backend call
> ends up being handled by a FUSE server that i am de= veloping). 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 get= attr is probably the result of unfsd doing a normal stat().
This is expected: When unfsd is "decomposing" a file handle i= nto a path,
it stat:s every file in the target directory (actually, plau= sible
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 th= e path name in that
> cache, could there be a stale entry in that cac= he? 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 st= ale, if that mapping is cached.

Murali

Regards,
--
Peter =C5strand     =       ThinLinc Chief Developer
Cendio AB          &n= bsp;    http://www.cendio.s= e
Teknikringen 3
583 30 Link=F6ping     =    Phone: +46-13-21 46 00

------=_Part_12431_6816516.1164220961797-- --===============0121585929== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV --===============0121585929== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs --===============0121585929==--