On Wed, 8 Apr 2009 13:05:31 -0400
Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> On Sun, Apr 05, 2009 at 09:09:20AM -0400, Jeff Layton wrote:
> > Add a new cifs_iget_unix function that uses iget5_locked to identify
> > inodes. This will compare inodes based on the UniqueId value that
> > the server provides when unix extensions are enabled. We also have
> > mounts with unix extensions use that value in the i_ino field (after
> > hashing it down to 32-bits on a 32-bit arches).
>
> Note that i_ino and ino_t aren't actually all that important. You
> already do the iget comparisms based on the internal uniqueid, so the
> only thing i_ino is used for is filling out the inode value in
> generic_fattr. I would suggest to fill it out explicitly in
> cifs_getattr so that you can actually return a 64bit ino there which
> is supported by stat64, possibly under and inode64 mount option.
>
Thanks, Christoph. That sounds reasonable. I'll do that with the next
iteration.
> > diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
> > index d958044..be639ee 100644
> > --- a/fs/cifs/dir.c
> > +++ b/fs/cifs/dir.c
> > @@ -187,18 +187,16 @@ int cifs_posix_open(char *full_path, struct inode **pinode,
> > if (!pinode)
> > goto posix_open_ret; /* caller does not need info */
> >
> > - if (*pinode == NULL) {
> > - __u64 unique_id = le64_to_cpu(presp_data->UniqueId);
> > - *pinode = cifs_new_inode(sb, &unique_id);
> > - }
> > + if (*pinode == NULL)
> > + *pinode = cifs_iget_unix_basic(sb, presp_data);
> > /* else an inode was passed in. Update its info, don't create one */
>
> Not directly related to this patch, but cifs_posix_open really needs
> some restructuring. The code up to the !pinode check should be the
> basic underlying helper, and the call to cifs_iget_unix_basic and
> posix_fill_in_inode should be moved to those callers that acutally need
> it.
>
Agreed, and that's not the only place. The current interfaces for this
stuff seem very ad-hoc. A primary goal that have with this patchset is
to not break anything and to keep the changes to a minimum, but I'd
like to see these cleaned up too.
--
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
