From: Hugo Mills <hugo@carfax.org.uk>
To: berodual_xyz <berodual_xyz@protonmail.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: parent transid verify failed / FS wont mount / help please!
Date: Mon, 25 Mar 2019 22:56:57 +0000 [thread overview]
Message-ID: <20190325225657.GE27856@carfax.org.uk> (raw)
In-Reply-To: <dJY4taBczsTC2XpF8mBue4O5brHguT2KuDS-bRHGA0fJ6m0o9z7bjHv0s2F6uvb0JZGISF-qkTWJT9bvl9ntyPbvq-FoOyQYCi0ZQ8_ShOw=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 4462 bytes --]
On Mon, Mar 25, 2019 at 10:51:24PM +0000, berodual_xyz wrote:
> Running "btrfs check" on the 3rd of the 4 devices the volume consists of crashes with a trace:
Just for the record, it doesn't matter which device you use for
btrfs check. You're running it on the whole filesystem, not just one
device. The device just serves to identify which FS you're running it
on. (The btrfs check code will scan all the available block devices
for the other pieces of the FS).
Hugo.
> ##
> $ btrfs check --readonly /dev/sdd
> Opening filesystem to check...
> parent transid verify failed on 1048576 wanted 60234 found 60230
> parent transid verify failed on 1048576 wanted 60234 found 60230
> Ignoring transid failure
> volumes.c:1762: btrfs_chunk_readonly: BUG_ON `!ce` triggered, value 1
> btrfs[0x426fdc]
> btrfs(btrfs_chunk_readonly+0x98)[0x429acd]
> btrfs(btrfs_read_block_groups+0x1c1)[0x41cd44]
> btrfs(btrfs_setup_all_roots+0x368)[0x416540]
> btrfs[0x416a8a]
> btrfs(open_ctree_fs_info+0xd0)[0x416bcc]
> btrfs(cmd_check+0x591)[0x45f431]
> btrfs(main+0x24a)[0x40ca02]
> /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fa320a44b35]
> btrfs[0x40c509]
> [1] 22848 abort btrfs check --readonly /dev/sdd
> ##
>
> Trying to mount "ro,usebackuproot" shows bad superblock and following errors in /var/log/messages:
>
> ##
> 33814.360633] BTRFS info (device sdd): trying to use backup root at mount time
> [33814.360637] BTRFS info (device sdd): using free space tree
> [33814.360638] BTRFS info (device sdd): has skinny extents
> [33814.361708] BTRFS error (device sdd): parent transid verify failed on 1048576 wanted 60234 found 60230
> [33814.361764] BTRFS error (device sdd): failed to read chunk root
> [33814.373140] BTRFS error (device sdd): open_ctree failed
> ##
>
>
> Again, thank you very much for all help!
>
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, March 25, 2019 11:44 PM, berodual_xyz <berodual_xyz@protonmail.com> wrote:
>
> > Thank you very much Hugo,
> >
> > the underlying devices are based on HW raid6 and effectively "stitched" together. Loosing any of those would mean loosing all data, so much is clear.
> >
> > My concern was not so much bitrod / silent data corruption but I would not have expected disabled data checksumming to be a disadvantage at recovering from the supposed corruption now.
> >
> > Does anyone have any input on how to restore files based on inode no. from the tree dump that I have?
> >
> > "usebackuproot,ro" did not succeed either.
> >
> > Much appreciate the input!
> >
> > Sent with ProtonMail Secure Email.
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Monday, March 25, 2019 11:38 PM, Hugo Mills hugo@carfax.org.uk wrote:
> >
> > > On Mon, Mar 25, 2019 at 10:26:29PM +0000, berodual_xyz wrote:
> > >
> > > > Dear all,
> > > > on a large btrfs based filesystem (multi-device raid0 - all devices okay, nodatacow,nodatasum...)
> > >
> > > Ouch. I think the only thing you could have done to make the FS
> > > more fragile is mounting with nobarrier(). Frankly, anything you're
> > > getting off it is a bonus. RAID-0 gives you no duplicate copy,
> > > nodatacow implies nodatasum, and nodatasum doesn't even give you the
> > > ability to detect data corruption, let alone fix it.
> > > With that configuration, I'd say pretty much by definition the
> > > contents of the FS are considered to be discardable.
> > > Restoring from backups is the recommended approach with transid
> > > failures.
> > > () Don't do that.
> > >
> > > > I experienced severe filesystem corruption, most likely due to a hard reset with inflight data.
> > > > The system cannot mount (also not with "ro,nologreplay" / "nospace_cache" etc.).
> > >
> > > Given how close the transids are, have you tried
> > > "ro,usebackuproot"? That's about your only other option at this
> > > point. But, if btrfs restore isn't working, then usebacuproot probably
> > > won't either.
> > >
> > > > Running "btrfs restore" I got a reasonable amount of data backed up, but a large chunk is missing.
> > > > "btrfs check" gives the following error:
--
Hugo Mills | I gave up smoking, drinking and sex once. It was the
hugo@... carfax.org.uk | scariest 20 minutes of my life.
http://carfax.org.uk/ |
PGP: E2AB1DE4 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2019-03-25 22:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-25 22:26 parent transid verify failed / FS wont mount / help please! berodual_xyz
2019-03-25 22:38 ` Hugo Mills
[not found] ` <kxQglfkZm7A_i8CXh0JVrJ9H0MF4vFVJWiT8BWRBc8NPM24nZC-vc6sIrts3ZR4T8HEvRTfPv1yz4lPotIuO1JiPYOk60cHMQqHcTFkDfZ4=@protonmail.com>
2019-03-25 22:51 ` berodual_xyz
2019-03-25 22:56 ` Hugo Mills [this message]
2019-03-25 23:07 ` berodual_xyz
2019-03-25 22:55 ` Hugo Mills
2019-03-26 3:47 ` Andrei Borzenkov
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=20190325225657.GE27856@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=berodual_xyz@protonmail.com \
--cc=linux-btrfs@vger.kernel.org \
/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