On Mon, Sep 05, 2022 at 08:35:39AM +0200, Christoph Hellwig wrote:
> On Fri, Sep 02, 2022 at 11:44:24AM +0200, David Sterba wrote:
> > > commit 6fd9210bc97710f81e5a7646a2abfd11af0f0c28
> > > Author: Christoph Hellwig <hch@xxxxxx>
> > > Date: Mon Feb 18 10:05:03 2019 +0100
> > >
> > > fstests: add a seek group
> > >
> > > So I'd like to let Christoph help to double check it.
> >
> > It's quite obvious from the test itself that it tests only send/receive,
> > which is mentioned in the changelog. The commit adding the seek group
> > does not provide any rationale so it's hard to argue but as it stands
> > now the 'seek' group should not be there.
>
> Probably. Unless it somehow exercised seeks through the userspace
> seek code I can't see any good rationale for this addition, and the
> patch was far too long ago for me to remember.
Hi,
I just tried to learn about the history of this *problem*:
At first, Jan Schmidt added src/fssum.c into fstests by df0fd18101b6 ("xfstests:
add fssum tool"). In this original version, fssum does SEEK_DATA in both
sum_file_data_permissive() and sum_file_data_strict(), that means it always
does SEEK_DATA. So all cases run fssum, need SEEK_DATA/HOLE support.
Then 5 years later, Filipe removed SEEK_DATA operations from the
sum_file_data_permissive(), by 1deed13f69b2 ("fstests: fix fssum to actually
ignore file holes when supposed to"). And fssum run sum_file_data_permissive()
by default. So that cause fssum don't need SEEK_DATA support by default (except
you use "-s" option).
Then 1 year later, Christoph added btrfs/007 into seek group, I think that might
because btrfs/007 still keeps the *_require_seek_data_hole*, which runs the
src/seek_sanity_test.
So, now, if we all agree that btrfs/007 isn't a seek related test, we can remove
the seek group and the *_require_seek_data_hole*.
Thanks,
Zorro
>
