On Thu, Feb 22, 2024 at 12:10 PM Steve French <smfrench@xxxxxxxxx> wrote: > > Changes to allocation size are approximated for extending writes of > cached files until the server returns the actual value (on SMB3 close > or query info for example), but it was setting the estimated value for > number of blocks to larger than the file size even if the file is > likely sparse which breaks various xfstests (e.g. generic/129, 130, > 221, 228). > > When i_size and i_blocks are updated in write completion do not > increase allocation size more than what was written (rounded up to 512 > bytes). > > See attached. > > This fixes the recent regression in various xfstests caused by the > xfstest change > > commit b4396efc75aba5325f22690303857af4f63d128e > Author: Alexander Patrakov <patrakov@xxxxxxxxx> > Date: Tue Dec 19 04:57:20 2023 +0800 > > _require_sparse_files: rewrite as a direct test instead of a black list > > > -- > Thanks, > > Steve + loff_t additional_blocks = (512 - 1 + copied) >> 9; There are chances that additional_blocks could lesser than this value. i.e. if the write started writes from before EOF. We could then calculate additional_blocks as more than it should be. I think there should be an additional check here: if (pos - copied) < i_size: additional_blocks should be based on pos - i_size. else additional_blocks should be based on copied. Regardless of this patch, is this really a bug? This is only an estimation that we do till we get the true value from the server. A filesystem is free to allocate blocks as necessary. This patch definitely improves this estimation though. -- Regards, Shyam