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