Re: [PATCH] generic: detect preallocation support for fsx tests 075 and 112

[Eryu Guan <guaneryu@gmail.com>]

On Mon, Feb 11, 2019 at 11:37:41AM +1100, Dave Chinner wrote:
> On Sun, Feb 10, 2019 at 07:11:42PM +0800, Eryu Guan wrote:
> > On Tue, Feb 05, 2019 at 07:47:13PM +0100, Christoph Hellwig wrote:
> > > Currently generic/075 and generic/112 have two extra fsx passes each that
> > > exercise fsx with preallocation, which are only enabled for XFS.
> > > 
> > > These tests can also be run with other file systems, given that the XFS
> > > prealloc ioctls are implemented in generic code since the addition of
> > > the fallocate system call.  This also means a version of XFS that does
> > > not support preallocation (e.g. because it always writes out of place)
> > > can skip the prealloc tests while still completing the normal fsx tests
> > > just fine.
> > > 
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > ---
> > >  tests/generic/075 | 16 +++++++++++-----
> > >  tests/generic/112 | 20 +++++++++++++-------
> > >  2 files changed, 24 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/tests/generic/075 b/tests/generic/075
> > > index 2b957891..8981c560 100755
> > > --- a/tests/generic/075
> > > +++ b/tests/generic/075
> > > @@ -48,11 +48,12 @@ _do_test()
> > >      echo "fsx.$_n : $_filter_param"
> > >      echo "-----------------------------------------------"
> > >  
> > > -    if [ "$FSTYP" != "xfs" ]
> > > -    then
> > > -	if [ "$_n" = "1" -o "$_n" = "3" ]
> > > -	then
> > > -	    # HACK: only xfs handles preallocation (-x) so just skip this test
> > > +    if [ "$_n" = "1" -o "$_n" = "3" ]; then
> > > +        if echo $testio | grep -q "Operation not supported"; then
> > 
> > Hmm, I don't think checking ENOSUPP message is sufficient, old distros
> > may ship xfs_io without falloc support or there's no generic prealloc
> > ioctl support, these cases are rare but possible.
> > 
> > How about adding a new XFS_IOC_RESVSP ioctl check in src/feature.c and
> 
> xfs_io -c "resvsp 0 1g" ...

But we have to check for different error messages caused by different
errnos again, and xfs_io doesn't set non-zero return value on failure,
so there's no easy way to check if XFS_IOC_RESVSP ioctl is succeeded or
not. I think it would be easier to do it in feature.c and we can rely on
the return value of 'feature'.

Or can we assume 'xfs -c "resvsp 0 1"' prints nothing on success, then
we could check if it prints out some kind error messages?

Thanks,
Eryu