From: Dave Chinner <david@fromorbit.com>
To: Lukas Czerner <lczerner@redhat.com>
Cc: Jayashree Mohan <jayashree2912@gmail.com>,
linux-xfs@vger.kernel.org,
Vijaychidambaram Velayudhan Pillai <vijay@cs.utexas.edu>,
Ashlie Martinez <ashmrtn@utexas.edu>,
fstests@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>
Subject: Re: XFS crash consistency bug : Loss of fsynced metadata operation
Date: Fri, 16 Mar 2018 11:19:55 +1100 [thread overview]
Message-ID: <20180316001955.GN18129@dastard> (raw)
In-Reply-To: <20180315103207.scrm5e4cvkj26m4k@rh_laptop>
On Thu, Mar 15, 2018 at 11:32:07AM +0100, Lukas Czerner wrote:
>
> And where the "cdcd" data is comming from ? Not from the
>
> "pwrite -S 1 0 64k"
>
> that's producing "0101".
Ah, too much context switching. Makes me look like the village
idiot...
Ok, I just spent some time looking at this in detail (event traces,
etc) and it is indeed as the test describes - an whole delalloc
extent allocation on partial overwrite. THe partial overwrite is
triggered by the fpunch/fzero code, and it appears the delalloc
converison is not paying attention to the start offset of the
writeback:
xfs_writepage: dev 7:0 ino 0x7603 pgoff 0xf000 size 0x10000 delalloc 1
.....
xfs_alloc_near_greater: dev 7:0 agno 0 agbno 3784 minlen 16 maxlen 16
.....
xfs_write_extent: dev 7:0 ino 0x7603 offset 0 block 3784 count 16 flag 0
IOWs, as I've said from the start (based on the test description)
this has nothing to do with the corruption issue CrashMonkey is
creating.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-03-16 0:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-13 2:15 XFS crash consistency bug : Loss of fsynced metadata operation Jayashree Mohan
2018-03-13 4:21 ` Dave Chinner
2018-03-13 6:36 ` Amir Goldstein
2018-03-13 18:05 ` Jayashree Mohan
2018-03-13 16:57 ` Jayashree Mohan
2018-03-13 22:45 ` Dave Chinner
2018-03-14 13:16 ` Lukas Czerner
2018-03-14 13:32 ` Dave Chinner
2018-03-14 13:57 ` Lukas Czerner
2018-03-14 21:24 ` Dave Chinner
2018-03-15 6:15 ` Lukas Czerner
2018-03-15 10:06 ` Dave Chinner
2018-03-15 10:32 ` Lukas Czerner
2018-03-16 0:19 ` Dave Chinner [this message]
2018-03-16 5:45 ` Lukas Czerner
2018-03-17 3:16 ` Dave Chinner
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=20180316001955.GN18129@dastard \
--to=david@fromorbit.com \
--cc=ashmrtn@utexas.edu \
--cc=fstests@vger.kernel.org \
--cc=jayashree2912@gmail.com \
--cc=lczerner@redhat.com \
--cc=linux-xfs@vger.kernel.org \
--cc=tytso@mit.edu \
--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.