On May 2, 2014, at 4:00 AM, George Pochiscan <george.pochis...@sphs.ro> wrote:
> Hello, > > I have a problem with a server with Fedora 20 and BTRFS. This server had > frequent hard restarts before the filesystem got corrupt and we are unable to > boot it. > > We have a HP Proliant server with 4 disks @1TB each and Software RAID 5. > It had Debian installed (i don't know the version) and right now i'm using > fedora 20 live to try to rescue the system. Fedora 20 Live has kernel 3.11.10 and btrfs-progs 0.20.rc1.20131114git9f0c53f-1.fc20. So the general rule of thumb without knowing exactly what the problem and solution is, is to try a much newer kernel and btrfs-progs, like a Fedora Rawhide live media. These are built daily, but don't always succeed so you can go here to find the latest of everything: https://apps.fedoraproject.org/releng-dash/ Find Fedora Live Desktop or Live KDE and click on details. Click the green link under descendants livecd. And then under Output listing you'll see an ISO you can download, the one there right now is Fedora-Live-Desktop-x86_64-rawhide-20140502.iso - but of course this changes daily. You might want to boot with kernel parameter slub_debug=- (that's a minus symbol) because all but Monday built Rawhide kernels have a bunch of kernel debug options enabled which makes it quite slow. > > When we try btrfsck /dev/md127 i have a lot of checksum errors, and the > output is: > > Checking filesystem on /dev/md127 > UUID: e068faf0-2c16-4566-9093-e6d1e21a5e3c > checking extents > checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11 > checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11 > checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11 > checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11 > Csum didn't match > checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9 > checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9 > checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9 > checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9 > Csum didn't match > ----------------------------------------------------------------- > > extent buffer leak: start 1006686208 len 4096 > found 32039247396 bytes used err is -22 > total csum bytes: 41608612 > total tree bytes: 388857856 > total fs tree bytes: 310124544 > total extent tree bytes: 22016000 > btree space waste bytes: 126431234 > file data blocks allocated: 47227326464 > referenced 42595635200 > Btrfs v3.12 I suggest a recent Rawhide build. And I suggest just trying to mount the file system normally first, and post anything that appears in dmesg. And if the mount fails, then try mount option -o recovery, and also post any dmesg messages from that too, and note whether or not it mounts. Finally if that doesn't work either then see if -o ro,recovery works and what kernel messages you get. > > > > When i attempt to repair i have the following error: > ----------------------------------------- > Backref 1005817856 parent 5 root 5 not found in extent tree > backpointer mismatch on [1005817856 4096] > owner ref check failed [1006686208 4096] > repaired damaged extent references > Failed to find [1000525824, 168, 4096] > btrfs unable to find ref byte nr 1000525824 parent 0 root 1 owner 1 offset 0 > btrfsck: extent-tree.c:1752: write_one_cache_group: Assertion `!(ret)' failed. > Aborted > ------------------------------------ You really shouldn't use --repair right off the bat, it's not a recommended early step, you should try normal mounting with newer kernels first, then recovery mount options first. Sometimes the repair option makes things worse. I'm not sure what its safety status is as of v3.14. https://btrfs.wiki.kernel.org/index.php/Problem_FAQ Fedora includes btrfs-zero-log already so depending on the kernel messages you might try that before a btrfsck --repair. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
