From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: dsterba@suse.cz, Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3 0/5] btrfs: Enhancement to tree block validation
Date: Thu, 24 Jan 2019 16:20:29 +0100 [thread overview]
Message-ID: <20190124152029.GX2900@twin.jikos.cz> (raw)
In-Reply-To: <0feee626-6d73-ba40-2e31-112ae5337f8d@gmx.com>
On Thu, Jan 24, 2019 at 11:04:47AM +0800, Qu Wenruo wrote:
>
>
> On 2019/1/24 上午1:16, David Sterba wrote:
> > On Fri, Jan 18, 2019 at 10:19:51AM +0800, Qu Wenruo wrote:
> >> Patchset can be fetched from github:
> >> https://github.com/adam900710/linux/tree/write_time_tree_checker
> >> Which is based on v5.0-rc1 tag.
> >>
> >> This patchset has the following two features:
> >> - Tree block validation output enhancement
> >> * Output validation failure timing (write time or read time)
> >> * Always output tree block level/key mismatch error message
> >> This part is already submitted and reviewed.
> >>
> >> - Write time tree block validation check
> >> To catch memory corruption either from hardware or kernel.
> >> Example output would be:
> >>
> >> BTRFS critical (device dm-3): corrupt leaf: root=2 block=1350630375424 slot=68, bad key order, prev (10510212874240 169 0) current (1714119868416 169 0)
> >> BTRFS error (device dm-3): write time tree block corruption detected
> >> BTRFS critical (device dm-3): corrupt leaf: root=2 block=1350630375424 slot=68, bad key order, prev (10510212874240 169 0) current (1714119868416 169 0)
> >> BTRFS error (device dm-3): write time tree block corruption detected
> >> BTRFS: error (device dm-3) in btrfs_commit_transaction:2220: errno=-5 IO failure (Error while writing out transaction)
> >> BTRFS info (device dm-3): forced readonly
> >> BTRFS warning (device dm-3): Skipping commit of aborted transaction.
> >> BTRFS: error (device dm-3) in cleanup_transaction:1839: errno=-5 IO failure
> >> BTRFS info (device dm-3): delayed_refs has NO entry
> >
> > Two tests complain:
>
> Any info about the reproducibility and VM/hardware info? Especially for
> the VM ram size.
2G ram with 4 cpus, this was first run of the patchset so I can't say
how reliable it is yet.
prev parent reply other threads:[~2019-01-24 15:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-18 2:19 [PATCH v3 0/5] btrfs: Enhancement to tree block validation Qu Wenruo
2019-01-18 2:19 ` [PATCH v3 1/5] btrfs: Always output error message when key/level verification fails Qu Wenruo
2019-01-18 7:38 ` Johannes Thumshirn
2019-01-18 2:19 ` [PATCH v3 2/5] btrfs: extent_io: Kill the forward declaration of flush_write_bio() Qu Wenruo
2019-01-18 2:19 ` [PATCH v3 3/5] btrfs: extent_io: Kill the BUG_ON() in flush_write_bio() Qu Wenruo
2019-01-22 17:38 ` David Sterba
2019-01-18 2:19 ` [PATCH v3 4/5] btrfs: disk-io: Show the timing of corrupted tree block explicitly Qu Wenruo
2019-01-18 7:39 ` Johannes Thumshirn
2019-01-18 2:19 ` [PATCH v3 5/5] btrfs: Do mandatory tree block check before submitting bio Qu Wenruo
2019-01-18 7:48 ` Johannes Thumshirn
2019-01-22 17:47 ` [PATCH v3 0/5] btrfs: Enhancement to tree block validation David Sterba
2019-01-22 22:53 ` Qu Wenruo
2019-01-23 17:16 ` David Sterba
2019-01-24 0:08 ` Qu Wenruo
2019-01-24 3:04 ` Qu Wenruo
2019-01-24 15:20 ` David Sterba [this message]
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=20190124152029.GX2900@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--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 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.