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