Re: parent transid verify failed on snapshot deletion

[Duncan <1i5t5.duncan@cox.net>]

Roman Mamedov posted on Sat, 12 Mar 2016 20:48:47 +0500 as excerpted:

> I wonder what's the best way to proceed here. Maybe try btrfs-zero-log?
> But the difference between transid numbers of 6 thousands is concerning.

btrfs-zero-log is a very specific tool designed to fix a very specific 
problem, and transid differences >1 are not it.

I read your followup, posting btrfs check output and wondering about 
enabling --repair, as well.

As long as you have a backup, shouldn't be a problem, even if it does 
cause further damage (which it doesn't appear like it will in your case).

If you don't have a backup it shouldn't be a problem either, since the 
very fact that you don't have a backup, indicates by your actions that 
you consider the data at risk as of less value than the time, effort and 
resources necessary to have that backup in the first place.   As such, 
even if you lose the data, you saved what was obviously more important 
than that data to you, the time, effort and resources that you would have 
otherwise put into making and testing that backup, so you're still coming 
out ahead. =:^)

Which means the only case not clearly covered is that of data worth 
having backed up, which you do, but the backup is somewhat stale, and as 
long as the risk was theoretical, you didn't consider the chance of 
something happening to the data updated since the backup worth more than 
the cost of updating that backup.  But now that the theoretical chance 
has become reality, while loss of that incremental data isn't earth 
shattering in its consequences, you'd prefer not to lose it if you can 
save it without too much trouble.  That's quite understandable, and is 
the exact position I've been in myself a couple times.

In both my cases where I did end up actually giving up on repair and 
eventually blowing away the filesystem, btrfs restore (before that blow-
away) was able to get me back the incremental changes since my last 
proper backup.  If it hadn't worked I'd have certainly lost some work and 
been less than absolutely happy, but as I _did_ have backups (which by 
the fact that I had them indicated I actually valued the data at risk at 
something above trivial), they were simply somewhat stale, it wouldn't 
have been the end of the world.


Of course in your case you _can_ mount, if only in read-only mode.  So 
take the opportunity you've been handed and update your backups (and of 
course backups that haven't been verified readable/restorable aren't yet 
completed backups, as a would-be backup isn't complete and can't really 
be considered a backup yet, until that verification is done), just in 
case, and then even in the worst-case scenario, btrfs check --repair 
can't do more than inconvenience you a bit if it makes the problem worse 
instead of fixing it, since you have current backups and will only need 
to blow away the filesystem and recreate it fresh, in ordered to restore 
them.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman