From: Jan Kara <jack@suse.cz>
To: Eryu Guan <eguan@redhat.com>
Cc: Jan Kara <jack@suse.cz>,
"Darrick J . Wong" <darrick.wong@oracle.com>,
linux-xfs@vger.kernel.org, Brian Foster <bfoster@redhat.com>
Subject: Re: [PATCH 0/3 v2] xfs: Fix SEEK_HOLE implementation
Date: Thu, 18 May 2017 11:03:46 +0200 [thread overview]
Message-ID: <20170518090346.GC9084@quack2.suse.cz> (raw)
In-Reply-To: <20170517145746.GC5632@quack2.suse.cz>
On Wed 17-05-17 16:57:46, Jan Kara wrote:
> On Wed 17-05-17 20:31:15, Eryu Guan wrote:
> > Hi Jan,
> >
> > On Wed, May 17, 2017 at 02:10:43PM +0200, Jan Kara wrote:
> > > Hello,
> > >
> > > this is the second revision of the patches to fix bugs in XFS's SEEK_HOLE
> > > implementation and cleanup the code a bit.
> > >
> > > Changes since v1:
> > > * Fixed some more buggy cases
> > > * Simplified code a bit as suggested by Darrick
> > > * Fixed range check as spotted by Brian
> >
> > I applied this patchset on top of 4.12-rc1 kernel to test your v4 test
> > case, your new test passed all my tests, but I found generic/285
> > regressed with sub-page block size XFS, 285.full showed that failure was
> > from subtest 7
> >
> > 07. Test file with unwritten extents, only have dirty pages
> > 07.01 SEEK_HOLE expected 0 or 11264, got 0. succ
> > 07.02 SEEK_HOLE expected 1 or 11264, got 1. succ
> > 07.03 SEEK_DATA expected 10240 or 10240, got -1. FAIL
> > 07.04 SEEK_DATA expected 10240 or 10240, got -1. FAIL
> >
> > And manual test showed subtest 8 failed too
> >
> > # ./src/seek_sanity_test -s 8 -e 8 /mnt/xfs/testfile
> > File system magic#: 0x58465342
> > Allocation size: 4096
> >
> > 08. Test file with unwritten extents, only have unwritten pages
> > 08.01 SEEK_HOLE expected 0 or 5632, got 0. succ
> > 08.02 SEEK_HOLE expected 1 or 5632, got 1. succ
> > 08.03 SEEK_DATA expected 5120 or 5120, got -1. FAIL
> > 08.04 SEEK_DATA expected 5120 or 5120, got -1. FAIL
> >
> > Other subtests all passed with sub-page block size XFS.
>
> Strange. It doesn't fail for me this way even with 1k blocksize. I'll
> investigate more tomorrow.
So I've been trying quite hard to reproduce the failure but I failed. Since
you are apparently getting some error out of lseek can you find out which
error it is (likely ENXIO but I'd like to confirm) and where it gets
generated? I don't see how it could possibly happen that SEEK_DATA would
miss that single page generated by this test and how any of my patches
would influence this particular situation. Thanks!
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2017-05-18 9:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-17 12:10 [PATCH 0/3 v2] xfs: Fix SEEK_HOLE implementation Jan Kara
2017-05-17 12:10 ` [PATCH 1/3] xfs: Fix missed holes in " Jan Kara
2017-05-17 12:10 ` Jan Kara
2017-05-17 12:10 ` [PATCH 2/3] xfs: Fix off-by-in in loop termination in xfs_find_get_desired_pgoff() Jan Kara
2017-05-17 12:10 ` [PATCH 3/3] xfs: Move handling of missing page into one place " Jan Kara
2017-05-17 12:31 ` [PATCH 0/3 v2] xfs: Fix SEEK_HOLE implementation Eryu Guan
2017-05-17 14:57 ` Jan Kara
2017-05-18 9:03 ` Jan Kara [this message]
2017-05-18 9:47 ` Eryu Guan
2017-05-18 10:10 ` Jan Kara
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=20170518090346.GC9084@quack2.suse.cz \
--to=jack@suse.cz \
--cc=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=eguan@redhat.com \
--cc=linux-xfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.