At 02/28/2017 02:51 AM, Andrei Borzenkov wrote:
This is VM under QEMU/KVM running openSUSE Tumbleweed. I boot it
infrequently for short time to test something. Last time it installed
quite a lot of updates including kernel (I think 4.9.11 was the last
version); I do not remember whether I rebooted it after that. Today I
booted it to check something, after 10 minutes did "reboot" and was
greeted with grub rescue prompt (it is located on btrfs itself and
apparently failed to read its modules as well). Any attempt to mount it
fails with "parent transid verfy failed". btrfsck --mode=lowmem from
current Tumbleweed snapshot runs for half an hour now with never-ending
same message.
Would you please provide the size of the fs?
lowmem mode is indeed slow, as it doesn't use much memory so it will do
tons of tree search instead, which will cause tons of same "parent
transid verify failed" if the corrupted node/leaf lies in a hot tree,
like root tree or extent tree.
Despite that, would you please try to run btrfsck original mode (default
mode) on the fs?
It may takes some memory but it's more mature than lowmem mode.
In fact there are near 10 bug fixes for lowmem mode mode merged yet.
I do not care in disk content really, but I would be interested in
trying to recover it under guidance. Also if it may be useful I can
provide image or other information.
Image would be best.
However I'm more interested how such problem happens.
In theory, Btrfs' mandatory metadata CoW and default data CoW should
keep btrfs bullet proof to any powerloss.
(While real world is far from theory)
Thanks,
Qu
TIA
-andrei
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
