public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: Eryu Guan <eguan@redhat.com>
To: Xiao Yang <yangx.jy@cn.fujitsu.com>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] generic/448: don't disable extent zeroing if extent_max_zeroout_kb isn't supported
Date: Wed, 19 Jul 2017 17:56:34 +0800	[thread overview]
Message-ID: <20170719095634.GD2478@eguan.usersys.redhat.com> (raw)
In-Reply-To: <596EC555.7020404@cn.fujitsu.com>

On Wed, Jul 19, 2017 at 10:35:01AM +0800, Xiao Yang wrote:
> On 2017/07/18 21:18, Eryu Guan wrote:
> > On Tue, Jul 18, 2017 at 04:27:50PM +0800, Xiao Yang wrote:
> > > On some old kernel(e.g. v3.5), this case fails because it can not create
> > > extent_max_zeroout_kb file, as below:
> > >    Silence is golden
> > >   +./tests/generic/448: line 54: /sys/fs/ext4/sda5/extent_max_zeroout_kb: No such file or directory
> > >    seek sanity check failed!
> > > 
> > > The extent_max_zeroout_kb file is introduced by:
> > >    67a5da564f97('ext4: make the zero-out chunk size tunable')
> > This is available since v3.7-rc1 kernel
> > $ git describe --contains 67a5da564f97
> > v3.7-rc1~91^2~63
> > 
> > But ext4 SEEK_DATA/SEEK_HOLE support was added in v3.8-rc1
> > $ git describe --contains c8c0df241cc2
> > v3.8-rc1~89^2~40
> > 
> > IMO, you shouldn't hit this error at all, because test won't pass
> > _require_seek_data_hole rule. (Unless you're testing some customized
> > kernel with seek_data/hole backported but not that ext4 sysfs entry.)
> Hi Eryu
> 
> Thanks for your explanation.
> 
> I test it in v3.5 kernel without seek_data/hole backported, please see the
> following message:
> [root@localhost xfstests]# uname -r
> 3.5.0
> [root@localhost xfstests]# src/seek_sanity_test -t
> /mnt/xfstests/test/testfile 2>&1
> File system magic#: 0xef53
> Allocation size: 4096
> File system supports the default behavior.

OK, I see why the test was *not* _notrun on 3.5 kernel now (without
seek_data/hole support added to ext4, but with SEEK_DATA/SEEK_HOLE flags
recognized by vfs, which was introduced by 982d81658 in v3.1-rc1),
because ext4 had the "default behavior" support, and that means "just
return i_size for SEEK_HOLE and will return the same offset for
SEEK_DATA".

> File system does not support unwritten extents.

This means the file system doesn't treat unwritten extents as a hole,
but data, which has nothing to do with SEEK_DATA/HOLE support status.

> 
> _require_seek_data_hole could not catch "File system does not support" if
> ext4 SEEK_DATA/SEEK_HOLE
> support was not added.
> 
> I think we should update  _require_seek_data_hole to catch both "Kernel does
> not support" and
> "File system does not support".   This case could be skipped when meetting
> either of them.

So this is wrong, IMO.

Thanks,
Eryu

  reply	other threads:[~2017-07-19  9:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-18  8:27 [PATCH] generic/448: don't disable extent zeroing if extent_max_zeroout_kb isn't supported Xiao Yang
2017-07-18 13:18 ` Eryu Guan
2017-07-19  2:35   ` Xiao Yang
2017-07-19  9:56     ` Eryu Guan [this message]
2017-07-19 10:38       ` Xiao Yang
2017-07-21  7:07         ` Eryu Guan
2017-07-24  9:49           ` [PATCH] common/rc: factor out _ext4_disable_extent_zeroout() helper Xiao Yang
2017-07-24 10:04             ` Eryu Guan
2017-07-24 10:33               ` Xiao Yang
2017-07-24 10:44               ` [PATCH v2] " Xiao Yang
2017-07-19  3:06   ` [PATCH] common/rc: update _require_seek_data_hole() Xiao Yang
2017-07-24  7:13   ` [PATCH] generic/448: don't disable extent zeroing if extent_max_zeroout_kb isn't supported Xiao Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170719095634.GD2478@eguan.usersys.redhat.com \
    --to=eguan@redhat.com \
    --cc=fstests@vger.kernel.org \
    --cc=yangx.jy@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox