On Tue, Mar 01, 2011 at 12:30:12PM -0600, Shirish Pargaonkar wrote:
> On Tue, Mar 1, 2011 at 12:07 PM, J. Bruce Fields <[email protected]> wrote:
> > On Mon, Feb 28, 2011 at 10:28:08PM -0500, J. Bruce Fields wrote:
> >> On Mon, Feb 28, 2011 at 08:33:08PM -0600, Steve French wrote:
> >> > On Mon, Feb 28, 2011 at 5:59 PM, J. Bruce Fields <[email protected]>
> >> > wrote:
> >> > > On Mon, Feb 28, 2011 at 05:52:09PM -0600, Steve French wrote:
> >> > >> On Mon, Feb 28, 2011 at 5:42 PM, J. Bruce Fields
> >> > >> <[email protected]> wrote:
> >> > >> > OK. Then as things stand we're stuck returning ESTALE to the client
> >> > >> > unless we happen to have the inode they're looking for in our cache?
> >> > >>
> >> > >> Yes - that seems right and consistent with what I remember other file
> >> > >> systems doing.
> >> > >
> >> > > No, other filesystems are able to look up the file on disk by inode
> >> > > number (or by whatever identifier they use in the filehandle). They
> >> > > don't depend on already having the inode in core.
> >> >
> >> > Grepping for ESTALE looks like there are dozens of places in various
> >> > fs where ESTALE can get returned ...
> >>
> >> Certainly true.
> >>
> >> But they do have to be able to look up any inode, regardless of whether
> >> it is currently in cache.
> >>
> >> Otherwise applications on the client would see ESTALE after any server
> >> reboot, or any time an inode was forced out of cache (for whatever
> >> reason).
> >>
> >> That would be quite painful.
> >
> > So if my understanding of the cifs behavior here is correct, then I
> > don't believe nfs exports of cifs will be usable.
> >
> > In the long term perhaps it could be possible with changes to one or the
> > other of the protocols: for example, perhaps future versions of the nfs
> > protocol could be made less reliant on long-lived filehandles. But that
> > would be a major change.
> >
> > --b.
> >
>
> Bruce, I am not getting a picture of how NFS server would return ESTALE
> error to nfs client and then on to the app for a filehandle fragment
> that happens
> to be coded as uniqueid by cifs during encode_fh if inode with that uniqueid
> does not happen to exist in vfs cache on the server box.
>
> When nfs passes down filehandle fragment (uniqueid) to cifs in fh_to_dentry,
> if the inode does not exist in cache, cifs will pick a new inode and copy this
> uniqueid as inode number.
Oh, OK, that's not what I'd imagined.
> Not sure what happens next for nfs server to
> sense a stale file(handle fragment).
What I'd expect to happen next:
- d_obtain_alias will find a dentry pointing at this inode.
(But, note: this dentry does *not* necessarily tell us anything
about any name of the file. In many cases it will be a
DCACHE_DISCONNECTED dentry with name "" and no parent.)
- at some later point, nfsd will attempt to open that dentry and
do reads or writes.
If the cifs/smb protocols give you some way to open or lookup by
uniqueid, then you can do step 2. I understood Steve to say that they
don't. In that case, you're stuck. But you're right, the failure may
be something other than returning ESTALE.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
