Re: [PATCH] cifs: Allow nfsd over cifs

[Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Mon, Feb 28, 2011 at 5:59 PM, J. Bruce Fields <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.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:
>> > On Mon, Feb 28, 2011 at 04:58:57PM -0600, Steve French wrote:
>> >> On Mon, Feb 28, 2011 at 4:49 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>> >> > On Mon, Feb 28, 2011 at 03:52:41PM -0600, shirishpargaonkar@gmail.com wrote:
>> >> >> +static struct dentry *
>> >> >> +cifs_fh_to_dentry(struct super_block *sb, struct fid *fh,
>> >> >> +                     int fh_len, int fh_type)
>> >> >> +{
>> >> >> +     struct cifs_fid *cfid = (struct cifs_fid *)fh;
>> >> >> +     struct inode *inode = NULL;
>> >> >> +     struct cifs_fattr fattr;
>> >> >> +
>> >> >>
>> >> >> -#endif /* CIFS_NFSD_EXPORT */
>> >> >> +     if (fh_type != FILEID_INO32_GEN && fh_type != FILEID_INO32_GEN_PARENT) {
>> >> >> +             cERROR(1, "%s: Can't handle fh type: %d", __func__, fh_type);
>> >> >> +             return ERR_PTR(-EINVAL);
>> >> >> +     }
>> >> >>
>> >> >> +     if (!cfid->cino)
>> >> >> +             return ERR_PTR(-ESTALE);
>> >> >> +
>> >> >> +     fattr.cf_uniqueid = cfid->cino;
>> >> >> +     inode = iget5_locked(sb, cfid->cino, cifs_find_inode_id,
>> >> >> +                                     cifs_init_inode, &fattr);
>> >> >> +     if (IS_ERR(inode))
>> >> >> +             return ERR_CAST(inode);
>> >> >> +
>> >> >> +     return d_obtain_alias(inode);
>> >> >
>> >> > Does the cifs protocol give the client a way to look up a file by inode
>> >> > number (or filehandle or equivalent?).
>> >>
>> >> There is a unique identifier similar to inode number returned by
>> >> various info calls,
>> >> but cifs calls use either a file handle (returned by an open) or path name to
>> >> look up metadata on a file.
>> >>
>> >> Not sure whether the unique identifier can be passed in as input to an
>> >> ioctl useful here.
>> >
>> > 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 ...

-- 
Thanks,

Steve