Re: parent transid verify failed / FS wont mount / help please!

[Hugo Mills <hugo@carfax.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 3416 bytes --]

On Mon, Mar 25, 2019 at 10:44:15PM +0000, berodual_xyz 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.

   OK, so it's not quite as bad a case as I painted. Turning off all
of the btrfs data-protection features still isn't something you'd do
to data you're friends with. However, it shouldn't directly affect the
recoverability of the data (assuming you had RAID-1 metadata).

   The main problem is that you've had a transid error, which is
pretty much universally fatal. There's a description of what that
means in the FAQ here:
https://btrfs.wiki.kernel.org/index.php/FAQ#What_does_.22parent_transid_verify_failed.22_mean.3F

> Does anyone have any input on how to restore files based on inode no. from the tree dump that I have?

   I'm not sure what you mean by "tree dump". Do you mean
btrfs-debug-tree? Or btrfs-image? Or something else? In any case, none
of those are likely to help all that much. The metadata is
corrupted in a way that shouldn't ever happen, and where it's really
hard to work out how to fix it, even with an actual human expert
involved.  (It's why there's no btrfs check fix for this situation --
you simply can't take the metadata broken in this way and make much
sense out of it).

   Hugo.

> "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 --]