Re: [PATCH] cifs: Allow nfsd over cifs

["J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>]

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@fieldses.org> 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@fieldses.org> 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.