For the common case of simply "ls" (vs "ls -l") does this affect
performance (have you double checked)?
On Fri, Oct 19, 2012 at 7:20 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> Otherwise, "ls -l" will simply show the ownership of the files as
> the default mnt_uid/gid. This may make "ls -l" performance on large
> directories super-suck in some cases, but that's the cost of cifsacl.
>
> One possibility to make it suck less would be to somehow proactively
> dispatch the ACL requests asynchronously from readdir codepath, but
> that's non-trivial to implement.
>
> Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
> ---
> fs/cifs/readdir.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/fs/cifs/readdir.c b/fs/cifs/readdir.c
> index f9b5d3d..96fe44b 100644
> --- a/fs/cifs/readdir.c
> +++ b/fs/cifs/readdir.c
> @@ -134,6 +134,16 @@ cifs_fill_common_info(struct cifs_fattr *fattr, struct cifs_sb_info *cifs_sb)
> if (fattr->cf_cifsattrs & ATTR_READONLY)
> fattr->cf_mode &= ~S_IWUGO;
>
> + /*
> + * We of course don't get ACL info in FIND_FIRST/NEXT results, so
> + * mark it for revalidation so that "ls -l" will look right. It might
> + * be super-slow, but if we don't do this then the ownership of files
> + * may look wrong since the inodes may not have timed out by the time
> + * "ls" does a stat() call on them.
> + */
> + if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_CIFS_ACL)
> + fattr->cf_flags |= CIFS_FATTR_NEED_REVAL;
> +
> if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_UNX_EMUL &&
> fattr->cf_cifsattrs & ATTR_SYSTEM) {
> if (fattr->cf_eof == 0) {
> --
> 1.7.11.7
>
--
Thanks,
Steve
--
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
