You are not logged in.
Hi,
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.
Regards
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)
Offline
HDD activity?
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
None.
Offline
Im on another laptop now but this is from my prompt on the laptop with btrfs:
"btrfsck /dev/sda4 --repair
enabling repair mode
checking extents
bad key ordering 26 27
bad block 423002112"
And a blinking cursor below.
Last edited by sPHERE (2013-01-13 17:22:17)
Offline
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
GitHub Junkyard
Offline
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?
Offline
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).
Offline
Please edit your first post and mark the thread [solved].
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
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.
Offline
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!
Offline