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@xxxxxxxx> But little nit picking on comments and useless final hunk: Steve French <smfrench@xxxxxxxxx> 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)
