The backtrace in your attachment looks like a known bug of 2.6.37 which have
already been fixed in 2.6.38. I have no idea why latest btrfs still hang in
your environment if there's no debug info...
-Original Message-
From: Maria Wikström [mailto:ma...@ponstudios.se]
Sent: Friday, Februa
Hi,
a recent Ubuntu upgrade killed my system. Luckily I had done a btrfs
snapshot before, so I set the particular subvolume as default using
# btrfs subvolume set-default 261 /mnt
from a rescue system and was back up in no time. I then mounted the
original volume with subvolid=0 and repaired it.
Hi,
the computer froze for a few seconds then this appeared in the log:
btrfs bad tree block start 9407756905013237084 32178176
There was no other messages from btrfs. I can mount, unmount, read,
write and all the data seems to be there. What does it mean? My guess is
that there was some kind of
sön 2011-02-20 klockan 13:22 +0100 skrev Christian Brunner:
> subscribe
You probably want to send
subscribe linux-btrfs
to majord...@vger.kernel.org instead :)
// Maria
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.
On 18.2.2011 21:18, Chris Mason wrote:
Ok, so it isn't part of the open devices code that prints errors, my
guess is we're failing to read a good super.
Could you please mkfs.btrfs /dev/xxx, sync, then btrfsck /dev/xxx, I want
to make sure things are really getting written.
Here's a patch that
