linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: tytso@mit.edu
To: Lukas Czerner <lczerner@redhat.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH 0/6 v2] Introduce FALLOC_FL_ZERO_RANGE flag for fallocate
Date: Sun, 16 Mar 2014 15:08:20 -0400	[thread overview]
Message-ID: <20140316190820.GB14162@thunk.org> (raw)
In-Reply-To: <1393355679-11160-1-git-send-email-lczerner@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

On Tue, Feb 25, 2014 at 08:14:33PM +0100, Lukas Czerner wrote:
> Introduce new FALLOC_FL_ZERO_RANGE flag for fallocate. This has the same
> functionality as xfs ioctl XFS_IOC_ZERO_RANGE.

Hi Lukas,

I've been trying to merge these patches into the ext4 tree, and I'm
running into a large number of test failures.  Could you take a quick
eyeball and see if there's anything obvious wrong?

The "dev2" branch in the ext4 git tree has all the patches in this
series (1, 2, and 5) --- 3 was included earlier applied on top of the
"dev" branch.  The "test" branch is the dev2 branch with the
xfs-collapse-range branch pulled in, which actually enables the
ZERO_RANGE flags (as well as the collapse range patches).

I have tested the "dev" branch both standalone and with the
xfs-collapse-range branch pulled in, and things seem to be pretty
stable.  I'm doing more comprehensive testing now to confirm things.
(I'm using xfstests commit id 3948694eb12 which has the latest tests
to exercise the zero_range codepath.)

When I tried testing with the "test" branch, things failed pretty
quickly.  I've attached two of these in this patch set.  I'm guessing
it's some kind of memory corruption problem.  These failures are
pretty repeatable, and it fails fast.

If I try running the "dev2" branch, without the xfstests collapse
range branch pulled in, things are much better (so there's clearly a
bug in the ZERO_RANGE code path), but there was still a few more
errors than the baseline.  I'm rerunning those tests so I can be sure
that the results are repeatable.

I suspect the problem is that something in the dev branch isn't
playing well with your patches, or I screwed up while fixing up some
merge conflicts -- but the merge conflicts were pretty minimal, so
that seems a bit unlikely.

Anyway, if you could take a look, I'd really appreciate it.  Thanks!!

	       	     	    	      	     - Ted


[-- Attachment #2: test-fail.tar.gz --]
[-- Type: application/octet-stream, Size: 34334 bytes --]

  parent reply	other threads:[~2014-03-16 19:08 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-25 19:14 [PATCH 0/6 v2] Introduce FALLOC_FL_ZERO_RANGE flag for fallocate Lukas Czerner
2014-02-25 19:14 ` [PATCH 1/6 v2] ext4: Update inode i_size after the preallocation Lukas Czerner
2014-03-16  3:27   ` tytso
2014-03-17  3:02   ` tytso
2014-03-17 10:48     ` Lukáš Czerner
2014-02-25 19:14 ` [PATCH 2/6 v2] ext4: refactor ext4_fallocate code Lukas Czerner
2014-03-16  3:28   ` tytso
2014-02-25 19:14 ` [PATCH 3/6 v2] ext4: translate fallocate mode bits to strings Lukas Czerner
2014-02-25 19:14 ` [PATCH 4/6 v2] fs: Introduce FALLOC_FL_ZERO_RANGE flag for fallocate Lukas Czerner
2014-02-25 19:14 ` [PATCH 5/6 v2] ext4: " Lukas Czerner
2014-02-26  6:00   ` jon ernst
2014-02-27  4:41     ` jon ernst
2014-02-27 11:56       ` Lukáš Czerner
2014-03-16  4:13   ` tytso
2014-02-25 19:14 ` [PATCH 6/6 v2] xfs: Add support for FALLOC_FL_ZERO_RANGE Lukas Czerner
2014-03-13  8:49 ` [PATCH 0/6 v2] Introduce FALLOC_FL_ZERO_RANGE flag for fallocate Dave Chinner
2014-03-13 10:14   ` Lukáš Czerner
2014-03-16 19:08 ` tytso [this message]
2014-03-17  2:19   ` tytso
2014-03-17 12:50     ` Lukáš Czerner
2014-03-17 13:29       ` tytso
2014-03-17 15:10         ` Lukáš Czerner
2014-03-17 20:57           ` tytso
2014-03-17 12:59   ` Lukáš Czerner
2014-03-17 21:00     ` tytso
2014-03-18  9:06       ` Lukáš Czerner
2014-03-18 11:37       ` Lukáš Czerner
2014-03-18 12:39         ` tytso
2014-03-18 12:52           ` Lukáš Czerner

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=20140316190820.GB14162@thunk.org \
    --to=tytso@mit.edu \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).