Re: [PATCH][SMB3 client] update allocation size more accurately on write completion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux