All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jayashree Mohan <jayashree2912@gmail.com>
To: Filipe Manana <fdmanana@kernel.org>
Cc: Eryu Guan <guaneryu@gmail.com>, fstests <fstests@vger.kernel.org>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	Filipe Manana <fdmanana@suse.com>,
	Vijaychidambaram Velayudhan Pillai <vijay@cs.utexas.edu>
Subject: Re: [PATCH] fstests: test btrfs fsync after hole punching with no-holes mode
Date: Mon, 2 Apr 2018 11:14:53 -0500	[thread overview]
Message-ID: <CA+EzBbBTO2rm3vufp-4wjXbkJ2Y82=KrUbuj_rs_q5fc4ZycjA@mail.gmail.com> (raw)
In-Reply-To: <CAL3q7H5ChFX-92CrNE7fOiTcVWLCxZ9=MQOFHc0WFNdVbUwSQQ@mail.gmail.com>

On Mon, Apr 2, 2018 at 9:24 AM, Filipe Manana <fdmanana@kernel.org> wrote:
> On Thu, Mar 29, 2018 at 7:55 PM, Jayashree Mohan
> <jayashree2912@gmail.com> wrote:
>> Hi Filipe,
>>
>> I tried running the xfstest above on kernel 4.15.0 and I haven't been
>> able to hit the bug. The xfstest passes clean for me. I compared the
>> btrfs-debug-tree in my case with the one attached by Eryu, and I see I
>> do not have any xattr as he does. However, for every run of the
>> xfstest, the extent tree info that I get from btrfs-debug-tree has
>> varying number of items in the first leaf node. (I have attached two
>> dump files for your reference.)
>>
>> I also tried changing the offset at which fpunch is performed to match
>> the offset of the last extent in the first leaf of the extent tree -
>> however the md5 before and after crash was the same.
>>
>> Could you give more details on this?
>
> You are getting extents smaller then 256Kb, because writeback is being
> triggered by the kernel (likely due to memory pressure).
> The second version of the test uses direct IO instead to avoid that.
> Thanks.

Thanks for the clarification. I am able to reproduce the bug with the
new version of the test that uses direct writes.

  reply	other threads:[~2018-04-02 16:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-26 22:59 [PATCH] fstests: test btrfs fsync after hole punching with no-holes mode fdmanana
2018-03-28  2:17 ` Eryu Guan
2018-03-28  8:48   ` Filipe Manana
2018-03-28 10:33     ` Eryu Guan
2018-03-29 13:45       ` Filipe Manana
2018-03-29 18:55         ` Jayashree Mohan
2018-04-02 14:24           ` Filipe Manana
2018-04-02 16:14             ` Jayashree Mohan [this message]
2018-03-30  0:58         ` Eryu Guan
2018-03-28 11:55 ` [PATCH v2] " fdmanana
2018-04-08  7:46   ` Eryu Guan
2018-04-08  8:46     ` Filipe Manana
2018-04-09 13:05       ` Eryu Guan
2018-04-16 11:28         ` Filipe Manana
2018-04-16 12:35           ` Eryu Guan

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='CA+EzBbBTO2rm3vufp-4wjXbkJ2Y82=KrUbuj_rs_q5fc4ZycjA@mail.gmail.com' \
    --to=jayashree2912@gmail.com \
    --cc=fdmanana@kernel.org \
    --cc=fdmanana@suse.com \
    --cc=fstests@vger.kernel.org \
    --cc=guaneryu@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=vijay@cs.utexas.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 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.