From: Adam Borowski <kilobyte@angband.pl>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH URGENT v1.1 0/2] btrfs-progs: Fix the nobarrier behavior of write
Date: Wed, 27 Mar 2019 15:07:48 +0100 [thread overview]
Message-ID: <20190327140748.GA30466@angband.pl> (raw)
In-Reply-To: <20190327094652.16078-1-wqu@suse.com>
On Wed, Mar 27, 2019 at 05:46:50PM +0800, Qu Wenruo wrote:
> This urgent patchset can be fetched from github:
> https://github.com/adam900710/btrfs-progs/tree/flush_super
> Which is based on v4.20.2.
>
> Before this patch, btrfs-progs writes to the fs has no barrier at all.
> All metadata and superblock are just buffered write, no barrier between
> super blocks and metadata writes at all.
>
> No wonder why even clear space cache can cause serious transid
> corruption to the originally good fs.
>
> Please merge this fix as soon as possible as I really don't want to see
> btrfs-progs corrupting any fs any more.
How often does this happen in practice? I'm slightly incredulous about
btrfs-progs crashing often. Especially that pwrite() is buffered on the
kernel side, so we'd need a _kernel_ crash (usually a power loss) to break
consistency. Obviously, a potential data loss bug is always something that
needs fixing, I'm just wondering about severity.
Or do I understand this wrong?
Asking because Dimitri John Ledkov stepped down as Debian's maintainer of
this package, and I'm taking up the mantle (with Nicholas D Steeves being
around) -- modulo any updates other than important bug fixes being on hold
because of Debian's freeze. Thus, I wonder if this is important enough to
ask for a freeze exception.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄⠀⠀⠀⠀
next prev parent reply other threads:[~2019-03-27 14:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-27 9:46 [PATCH URGENT v1.1 0/2] btrfs-progs: Fix the nobarrier behavior of write Qu Wenruo
2019-03-27 9:46 ` [PATCH URGENT v1.1 1/2] btrfs-progs: disk-io: Make super block write error easier to read Qu Wenruo
2019-03-27 11:34 ` Nikolay Borisov
2019-03-27 9:46 ` [PATCH URGENT v1.1 2/2] btrfs-progs: disk-io: Flush to ensure super block write is FUA Qu Wenruo
2019-03-27 14:07 ` Adam Borowski [this message]
2019-03-27 14:17 ` [PATCH URGENT v1.1 0/2] btrfs-progs: Fix the nobarrier behavior of write Hugo Mills
2019-03-27 14:39 ` Qu Wenruo
2019-03-27 14:42 ` Qu Wenruo
2019-03-27 14:48 ` Qu Wenruo
2019-03-31 14:42 ` Qu Wenruo
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=20190327140748.GA30466@angband.pl \
--to=kilobyte@angband.pl \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@suse.com \
/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