I got a new laptop about a month ago, and did a clean install of Arch linux on it, with btrfs on root and home.
Last couple of days the /home partition has become corrupted, btrfsck says "bad key ordering" and "bad block".
So right now Im doing "btrfsck --repair /dev/sda4", and nothing have happened in about an hour.
How long is this supposed to take?
I got about 50gigs of data on that partition, mostly movies.
EDIT: It's been over 2 hours now. Still the same output and a blinking cursor. Im using SysRescueCD 3.2 btw.
Last edited by sPHERE (2013-01-13 17:00:19)
Im on another laptop now but this is from my prompt on the laptop with btrfs:
"btrfsck /dev/sda4 --repair
enabling repair mode
bad key ordering 26 27
bad block 423002112"
And a blinking cursor below.
Last edited by sPHERE (2013-01-13 17:22:17)
Log to another tty and look into dmesg, it's possible that the hdd choked on something.
'What can be asserted without evidence can also be dismissed without evidence.' - Christopher Hitchens
'There's no such thing as addiction, there's only things that you enjoy doing more than life.' - Doug Stanhope
I ran "dmesg | grep btrfs" and "btrfsck" but no results. Also cant see anything of interesent when I just run dmesg.
Im not too familiar with dmesg sorry.. Is there another way?
I seemed to have fixed it now.
This is what I did:
I canceled the btrfsck operation in SystemRescueCD, and tried the repairfunction from within Gparted (still in Sysrcd).
This didn't work either, so I tried mounting the filesystem with the "recovery" option. This gave me no errors, but also no progress. Had to cancel this also.
So I did btrfs-zero-log /dev/sda4, rebooted. Not succesful.
So I downloaded the latest Gparted live-iso, and put in on a USB-stick.
Booted it up, and did "btrfsck --repair /dev/sda4". This time, it completed within 5minutes and gave me information about what it did to the filesystem.
I then did "btrfs-zero-log /dev/sda4" again. Rebooted, and voila - It worked.
This is now SOLVED (for now).
Please edit your first post and mark the thread [solved].
You should be aware that since you are using a still experimental filesystem, the tools are ever changing. So you should always be trying to use the newest versions. I think this would be a good justification for having the tools in a separate bare necessities installation on your drive.
I know this is a dead thread, but I'm replying anyway because it wasn't sufficiently answered.
When you run btrfsck you do indeed get an empty cursor line with no output. In another terminal screen, you can then
ps aux | grep btrfsck
or "pidof btrfsck" to get the process ID. Then, you can "strace -p <the process id>" to actually trace out the system calls and signals in the kernel.
Helpful one-liner to do all this:
pidof btrfsck | xargs strace -p
Doing that should show you that the btrfsck process is, in fact, grinding away really hard trying to reassemble/repair/check the filesystem.
A second way to see if anything is happening, and possibly to confirm that the btrfsck is actually using/accessing the disk device in question is to run "atop" on it, which should show you disk usage, like so:
$ atop ... DSK | sdc | busy 100% | read 6 | write 0 | KiB/r 4 | KiB/w 0 | MBr/s 0.00 | MBw/s 0.00 | avio 1662 ms | ...
This indicates to me that the btrfsck is running and predictably spinning out of that disk device. It'd go faster if only the disk would ;-)
Hope this helps!