On Fri, Apr 17, 2020 at 6:10 PM Brian Foster <bfoster@xxxxxxxxxx> wrote:
>
> On Wed, Apr 08, 2020 at 11:35:52AM +0100, fdmanana@xxxxxxxxxx wrote:
> > From: Filipe Manana <fdmanana@xxxxxxxx>
> >
> > When a zero range operation increases the size of the test file we were
> > not updating the global variable 'file_size' which tracks the current
> > size of the test file. This variable is used to for example compute the
> > offset for a source range of clone, dedupe and copy file range operations.
> >
> > So just fix it by updating the 'file_size' global variable whenever a zero
> > range operation does not use the keep size flag and its range goes beyond
> > the current file size.
> >
> > Signed-off-by: Filipe Manana <fdmanana@xxxxxxxx>
> > ---
> > ltp/fsx.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/ltp/fsx.c b/ltp/fsx.c
> > index 9d598a4f..fa383c94 100644
> > --- a/ltp/fsx.c
> > +++ b/ltp/fsx.c
> > @@ -1212,6 +1212,8 @@ do_zero_range(unsigned offset, unsigned length, int keep_size)
> > }
> >
> > end_offset = keep_size ? 0 : offset + length;
> > + if (!keep_size && end_offset > file_size)
> > + file_size = end_offset;
>
> Should this ever happen if the caller uses TRIM_OFF_LEN() on the
> offset and length?
TRIM_OFF_LEN only trims the range, not the file_size.
Or did I miss something?
Thanks.
>
> Brian
>
> >
> > if (end_offset > biggest) {
> > biggest = end_offset;
> > --
> > 2.11.0
> >
>
