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 <bfields@xxxxxxxxxxxx> 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 <bfields@xxxxxxxxxxxx> 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 <bfields@xxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
