From: "Lukáš Czerner" <lczerner@redhat.com>
To: tytso@mit.edu
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH 0/6 v2] Introduce FALLOC_FL_ZERO_RANGE flag for fallocate
Date: Mon, 17 Mar 2014 13:59:35 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.00.1403171358580.30625@localhost.localdomain> (raw)
In-Reply-To: <20140316190820.GB14162@thunk.org>
On Sun, 16 Mar 2014, tytso@mit.edu wrote:
> Date: Sun, 16 Mar 2014 15:08:20 -0400
> 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
>
> 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
That's definitely very weird and I have not seen that before. i am
looking into this right not.
Thanks!
-Lukas
>
>
next prev parent reply other threads:[~2014-03-17 12:59 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
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 [this message]
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=alpine.LFD.2.00.1403171358580.30625@localhost.localdomain \
--to=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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).