From: Hugo Mills <hugo@carfax.org.uk>
To: Thomas Wurfbaum <thomas@wurfbaum.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Crashed filesystem, nothing helps
Date: Wed, 2 Aug 2017 09:07:09 +0000 [thread overview]
Message-ID: <20170802090709.GA7140@carfax.org.uk> (raw)
In-Reply-To: <1569935.QpkscbukDQ@nimrod.thomas.wurfbaum.net>
[-- Attachment #1: Type: text/plain, Size: 8438 bytes --]
On Wed, Aug 02, 2017 at 10:27:50AM +0200, Thomas Wurfbaum wrote:
> Hello,
>
> Yesterday morning i recognized a hard reboot of my system, but the /data
> filesystem was
> not possible to mount.
>
>
> mainframe:~ # uname -a
> Linux mainframe 4.11.8-2-default #1 SMP PREEMPT Thu Jun 29 14:37:33 UTC 2017
> (42bd7a0) x86_64 x86_64 x86_64 GNU/Linux
> mainframe:~ # btrfs --version
> btrfs-progs v4.10.2+20170406
> mainframe:~ # btrfs fi show
> Label: none uuid: 22aaaa76-0885-4683-ac04-477c27cfab80
> Total devices 1 FS bytes used 2.88TiB
> devid 1 size 4.53TiB used 2.92TiB path /dev/sdb1
> mainframe:~ # btrfs restore /dev/sdb1 /mnt
> parent transid verify failed on 29392896 wanted 1486833 found 1486836
> parent transid verify failed on 29392896 wanted 1486833 found 1486836
> parent transid verify failed on 29392896 wanted 1486833 found 1486836
> parent transid verify failed on 29392896 wanted 1486833 found 1486836
> Ignoring transid failure
> parent transid verify failed on 29409280 wanted 1486829 found 1486833
> parent transid verify failed on 29409280 wanted 1486829 found 1486833
> parent transid verify failed on 29409280 wanted 1486829 found 1486833
> parent transid verify failed on 29409280 wanted 1486829 found 1486833
> Ignoring transid failure
> parent transid verify failed on 29376512 wanted 1327723 found 1486833
> parent transid verify failed on 29376512 wanted 1327723 found 1486833
> parent transid verify failed on 29376512 wanted 1327723 found 1486833
> parent transid verify failed on 29376512 wanted 1327723 found 1486833
> Ignoring transid failure
> mainframe:~ # mount /dev/sdb1 /data
> mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
> missing codepage or helper program, or other error
>
> In some cases useful info is found in syslog - try
> dmesg | tail or so.
> mainframe:~ # mount -o usebackuproot /dev/sdb1 /data
> mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
> missing codepage or helper program, or other error
>
> In some cases useful info is found in syslog - try
> dmesg | tail or so.
> mainframe:~ # btrfs check /dev/sdb1
> parent transid verify failed on 29392896 wanted 1486833 found 1486836
> parent transid verify failed on 29392896 wanted 1486833 found 1486836
> parent transid verify failed on 29392896 wanted 1486833 found 1486836
> parent transid verify failed on 29392896 wanted 1486833 found 1486836
> Ignoring transid failure
> parent transid verify failed on 29409280 wanted 1486829 found 1486833
> parent transid verify failed on 29409280 wanted 1486829 found 1486833
> parent transid verify failed on 29409280 wanted 1486829 found 1486833
> parent transid verify failed on 29409280 wanted 1486829 found 1486833
> Ignoring transid failure
> parent transid verify failed on 29376512 wanted 1327723 found 1486833
> parent transid verify failed on 29376512 wanted 1327723 found 1486833
> parent transid verify failed on 29376512 wanted 1327723 found 1486833
> parent transid verify failed on 29376512 wanted 1327723 found 1486833
> Ignoring transid failure
> Checking filesystem on /dev/sdb1
> UUID: 22aaaa76-0885-4683-ac04-477c27cfab80
> checking extents
> parent transid verify failed on 290766848 wanted 1486826 found 1486085
> parent transid verify failed on 290766848 wanted 1486826 found 1486085
> parent transid verify failed on 290766848 wanted 1486826 found 1486085
> parent transid verify failed on 290766848 wanted 1486826 found 1486085
> Ignoring transid failure
> parent transid verify failed on 292339712 wanted 1486826 found 1486086
> parent transid verify failed on 292339712 wanted 1486826 found 1486086
> parent transid verify failed on 291078144 wanted 1486826 found 1486085
> parent transid verify failed on 291078144 wanted 1486826 found 1486085
> parent transid verify failed on 291078144 wanted 1486826 found 1486085
> parent transid verify failed on 291078144 wanted 1486826 found 1486085
> Ignoring transid failure
> parent transid verify failed on 292978688 wanted 1486826 found 1486086
> parent transid verify failed on 292978688 wanted 1486826 found 1486086
> parent transid verify failed on 292978688 wanted 1486826 found 1486086
> parent transid verify failed on 292978688 wanted 1486826 found 1486086
> Ignoring transid failure
> parent transid verify failed on 292519936 wanted 1486826 found 1486086
> parent transid verify failed on 292519936 wanted 1486826 found 1486086
> parent transid verify failed on 292536320 wanted 1486826 found 1486086
> parent transid verify failed on 292536320 wanted 1486826 found 1486086
> parent transid verify failed on 292552704 wanted 1486826 found 1486086
> parent transid verify failed on 292552704 wanted 1486826 found 1486086
> parent transid verify failed on 292585472 wanted 1486826 found 1486086
> parent transid verify failed on 292585472 wanted 1486826 found 1486086
> parent transid verify failed on 292585472 wanted 1486826 found 1486086
> parent transid verify failed on 292585472 wanted 1486826 found 1486086
> Ignoring transid failure
> parent transid verify failed on 290766848 wanted 1486826 found 1486085
> Ignoring transid failure
> leaf parent key incorrect 290766848
> bad block 290766848
> ERROR: errors found in extent allocation tree or chunk allocation
> parent transid verify failed on 290766848 wanted 1486826 found 1486085
> Ignoring transid failure
> leaf parent key incorrect 290766848
> ERROR: failed to repair root items: Operation not permitted
> mainframe:~ # btrfs rescue super-recover /dev/sdb1
> All supers are valid, no need to recover
> mainframe:~ # btrfs rescue zero-log /dev/sdb1
> parent transid verify failed on 29392896 wanted 1486833 found 1486836
> parent transid verify failed on 29392896 wanted 1486833 found 1486836
> parent transid verify failed on 29392896 wanted 1486833 found 1486836
> parent transid verify failed on 29392896 wanted 1486833 found 1486836
> Ignoring transid failure
> parent transid verify failed on 29409280 wanted 1486829 found 1486833
> parent transid verify failed on 29409280 wanted 1486829 found 1486833
> parent transid verify failed on 29409280 wanted 1486829 found 1486833
> parent transid verify failed on 29409280 wanted 1486829 found 1486833
> Ignoring transid failure
> parent transid verify failed on 29376512 wanted 1327723 found 1486833
> parent transid verify failed on 29376512 wanted 1327723 found 1486833
> parent transid verify failed on 29376512 wanted 1327723 found 1486833
> parent transid verify failed on 29376512 wanted 1327723 found 1486833
> Ignoring transid failure
> Clearing log on /dev/sdb1, previous log_root 0, level 0
> parent transid verify failed on 29474816 wanted 1486833 found 1486837
> Ignoring transid failure
> leaf parent key incorrect 29474816
> disk-io.c:524: update_cowonly_root: BUG_ON `ret` triggered, value -1
> btrfs(+0x26304)[0x555686369304]
> btrfs(btrfs_commit_transaction+0x98)[0x55568636aed8]
> btrfs(+0x69efa)[0x5556863acefa]
> btrfs(main+0x84)[0x555686361e34]
> /lib64/libc.so.6(__libc_start_main+0xf1)[0x7f43653df291]
> btrfs(_start+0x2a)[0x555686361f4a]
> Aborted (core dumped)
> mainframe:~ # btrfs rescue chunk-recover /dev/sdb1
> This command still runs, even after 15 hours.
> Is there anything else i could do?
Well, a good start would be to take a time machine and go back a
day or so and not run all the random recovery tools you can get your
hands on... Most of them are quite specialised (super-recover,
chunk-recover, zero-log). It's fairly unlikely that they've made
things worse, but it's not certain. Certainly zero-log will have
modified the filesystem. I don't know about the other two.
More productively, it's definitely worth trying to mount with the
-o usebackuproot option. (And -o usebackuproot,ro as well). The
transid verify failure is a small difference in generations, and it's
likely that the older metadata is still there. If that's the case, the
mount with usebackuproot will work, and you should be good to continue
as normal.
If that doesn't work, then btrfs restore to refresh your backups is
probably the way to go, followed by mkfs and restore from backup.
Hugo.
--
Hugo Mills | "How deep will this sub go?"
hugo@... carfax.org.uk | "Oh, she'll go all the way to the bottom if we don't
http://carfax.org.uk/ | stop her."
PGP: E2AB1DE4 | U571
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2017-08-02 9:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-02 8:27 Crashed filesystem, nothing helps Thomas Wurfbaum
2017-08-02 8:29 ` Thomas Wurfbaum
2017-08-02 9:07 ` Hugo Mills [this message]
2017-08-02 9:17 ` Thomas Wurfbaum
2017-08-02 9:31 ` Roman Mamedov
2017-08-02 9:33 ` Thomas Wurfbaum
2017-08-02 9:41 ` Thomas Wurfbaum
2017-08-07 5:12 ` Thomas Wurfbaum
2017-08-07 8:47 ` Henk Slager
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=20170802090709.GA7140@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
--cc=thomas@wurfbaum.net \
/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