Re: [PATCH] cifs: fix allocation size on newly created files

["Aurélien Aptel" <aaptel@suse.com>]

I gave it a try and it seems correct, alloc size is zero without the
patch, despite size being >0.

The estimate seems reasonable, it will get updated when cache timeout
runs out.

Server is supposed to return newly allocated blocks on Close Response
but I see it's zero on Windows Server despite file size being >0 (maybe
server bug).

In any case change looks ok, you can

Reviewed-by: Aurelien Aptel <aaptel@suse.com>

But little nit picking on comments and useless final hunk:

Steve French <smfrench@gmail.com> writes:
> + /*
> + * i_blocks is not related to (i_size / i_blksize),
> + * but instead 512 byte (2**9) size is required for
> + * calculating num blocks. Until we can query the
> + * server for actual allocation size, this is best estimate
> + * we have for the blocks allocated for this file
> + */
> + inode->i_blocks = (512 - 1 + attrs->ia_size) >> 9;

I would put in the comment: number of 512bytes blocks rounded up, much
easier to read.

>
>   /*
>   * The man page of truncate says if the size changed,
> @@ -2912,7 +2920,7 @@ cifs_setattr_nounix(struct dentry *direntry,
> struct iattr *attrs)
>   sys_utimes in which case we ought to fail the call back to
>   the user when the server rejects the call */
>   if ((rc) && (attrs->ia_valid &
> - (ATTR_MODE | ATTR_GID | ATTR_UID | ATTR_SIZE)))
> +     (ATTR_MODE | ATTR_GID | ATTR_UID | ATTR_SIZE)))
>   rc = 0;
>   }

You should remove that hunk, it's not doing anything

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)