Re: mkfs or wait?
I had a similar issue There was a Segmenation fault showing up in dmesg that wasen't showing up in /var/log/messages. In my case upgrading to the git tree let me read and write to the filesystem. On Tue, Sep 7, 2010 at 9:45 AM, Lubos Kolouch lubos.kolo...@gmail.com wrote: Lubos Kolouch, Tue, 07 Sep 2010 05:55:12 +: Hello, I have on one computer damaged btrfs filesystem... it was a strange crash, it showed about 30% free space, however then the volume crashed with 'no space left' messages and after reboot it is unusable. I can mount it, I can df it but when I try for example ls, ls gets stuck (does not display anything) and I get - in the syslog verify_parent_transid: 22336 callbacks suppressed parent transid verify failed on 1066975232 wanted 125077 found 125075 parent transid verify failed on 974635008 wanted 125077 found 125075 parent transid verify failed on 1066975232 wanted 125077 found 125075 parent transid verify failed on 974635008 wanted 125077 found 125075 parent transid verify failed on 1066975232 wanted 125077 found 125075 parent transid verify failed on 974635008 wanted 125077 found 125075 parent transid verify failed on 1066975232 wanted 125077 found 125075 parent transid verify failed on 974635008 wanted 125077 found 125075 parent transid verify failed on 1066975232 wanted 125077 found 125075 parent transid verify failed on 974635008 wanted 125077 found 125075 - top shows ls [btrfs-endio-met] [btrfs-cache-293] - btrfs segfaults It is like this over a day. Should I just mkfs it or is there anything sensible I could try? kernel 2.6.35-gentoo-r5, latest git btrfs-progs Thank you for your advice. Lubos Funny thing - under 2.6.34-r1 it works, ie. I can mount it and view files (even though the errors in log are still there). Regression in 2.6.35? Lubos -- 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 -- S.D.G. -- 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
Re: Recover Corruption - verify_parent_transid
I had a system in a simelar situation. In my case the fix was to upgrade the btrfs module to git-head. After I did that tryig to mount gave me an error is syslog about a problem it was having with one disk before it went into the transid loop. i remove the disk and re-mounted with -o degraded. hat allowed me to actually get teh drives mounted. If your on a single disk setup i don't think that would work for you. what you can do is check the syslog as you try to mount for any OOP's that you may be able to fix. On Tue, Aug 10, 2010 at 12:37 AM, A. James Lewis ja...@fsck.co.uk wrote: Not being one of the developers on this project, I cannot offer you a solution to recovering data from this volume, and my guess is that a ready solution is unlikely to be forthcoming simply because if this was possible then btrfsck would include the code to recover the filesystem already. However, rather than simply observe that anything not backed up is lost... I thought I would offer the solution of the 4th dimension The data is not lost, but simply unavailable to you until the tools to repair the filesystem have been developed further. If I had something critical which had become inaccessible, I might be tempted to put the drive on a shelf for 6 months and see if btrfsck was able to repair filesystems by then. It may be that the on disk format is changed before that happens, but I understand that this is now relatively unlikely. A. James Lewis -- 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 -- S.D.G. -- 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
Re: boot problem
Lubos , If you have a multi-device btrfs filesystem you need to run btrfsctrl -a to have the kernel register the filesystem. Tehre were some open bug reports about this in various distros. https://bugzilla.redhat.com/show_bug.cgi?id=498445 http://bugs.gentoo.org/show_bug.cgi?id=309219 http://ubuntuforums.org/showthread.php?t=1456494 On Fri, Jul 9, 2010 at 11:06 AM, Lubos Kolouch lubos.kolo...@gmail.com wrote: Hello, I added another device to the / filesystem (btrfs device add). Now I can't boot off it, even though kernel sees both devices (sda2, sdb2). Am I screwed or is there any way how to convince the kernel to assemble the / filesystem? Thank you Lubos -- 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 -- S.D.G. -- 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
Re: volume broken? btrfsck fails
Looks like we're looping on a single block. What happens when you dmesg -n1 to cut down on the console traffic? Nothing changes I still have endless repeats of parent transid verify failed on 1682586464256 wanted 285114 found 11257 If that doesn't help we can change it to spit a stack trace to figure out where the looping is happening. We should be erroring out instead of hitting it over and over again. In my kernel noviceness i tried attaching gdb to the btrfs-endio-met, however apparently you can't attach gdb to a kernel thread like that If you could assist me in obtaining a call trace I will gladly attempt to resolve the matter. Ok I had some free time and decided to excersice my googlefoo and came up with this trace parent transid verify failed on 3241193205760 wanted 285287 found 281382 Pid: 2163, comm: mount Not tainted 2.6.35-0.23.rc3.git6.fc14.x86_64 #1 Call Trace: [a047c376] verify_parent_transid+0xb7/0xfe [btrfs] [a047c4f2] btrfs_buffer_uptodate+0x49/0x59 [btrfs] [a04686a2] read_block_for_search+0x8f/0x289 [btrfs] [a046d554] btrfs_search_slot+0x3ae/0x513 [btrfs] [a0470ece] btrfs_read_block_groups+0x73/0x526 [btrfs] [8149b0a3] ? _raw_spin_unlock+0x2b/0x2f [a0469f56] ? btrfs_root_node+0x2a/0x32 [btrfs] [a047d287] ? find_and_setup_root+0xab/0xbc [btrfs] [a04800eb] open_ctree+0xf19/0x143a [btrfs] [a0467960] btrfs_get_sb+0x1ce/0x40b [btrfs] [810e9cfd] ? free_pages+0x49/0x4e [8112c9f9] vfs_kern_mount+0xbd/0x19b [8112cb3f] do_kern_mount+0x4d/0xed [81143742] do_mount+0x776/0x7ed [81143841] sys_mount+0x88/0xc2 [81009c32] system_call_fastpath+0x16/0x1b Dan Kozlowski -- S.D.G. -- S.D.G. -- 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
Re: volume broken? btrfsck fails
On Tue, Jul 6, 2010 at 8:19 PM, Chris Mason chris.ma...@oracle.com wrote: I am also having the same problem with a slightly different setup. In My case I cannot mount the filesystem. What is your hardware setup here? Including write cache settings. Did you have craces with 2.6.35-rc1 or rc2? My setup is Eight hard Drive four 1TB Drives four 500GB Drives All drives are connected through a 3ware Inc 9550SX SATA-II RAID PCI-X card The card is configured to export all drives essentially acting as a SATA port multiplier. (drives show up sdb - sdi) Drives are configured in btrfs raid0 Filesystem is mounted using: mount -t btrfs /dev/sdb /opt I have been able to lock up the system on 2.6.33.5-124.fc13.x86_64 2.6.35-0.13.rc3.git2.fc14.x86_64 2.6.35-0.23.rc3.git6.fc14.x86_64 and 2.6.35-0.23.rc3.git6.fc14.x86_64 with a DKMS build of the btrfs module (Btrfs v0.19-16-g075587c-dirty) If you would like me to pull out another version of the kernel or roll back specific commits from the kernel module I can I have been able to get different responses form different version 2.6.33.* - This will mount the volume but will hang shortly after mounting when reading data form the filesystem ( ls /opt) writes a bunch of transid verify failed messages hangs on ls 2.6.34.* - Will not mount at all still gives the transid verify failed hands on mount Looks like we're looping on a single block. What happens when you dmesg -n1 to cut down on the console traffic? Nothing changes I still have endless repeats of parent transid verify failed on 1682586464256 wanted 285114 found 11257 If that doesn't help we can change it to spit a stack trace to figure out where the looping is happening. We should be erroring out instead of hitting it over and over again. In my kernel noviceness i tried attaching gdb to the btrfs-endio-met, however apparently you can't attach gdb to a kernel thread like that If you could assist me in obtaining a call trace I will gladly attempt to resolve the matter. Dan Kozlowski -- S.D.G. -- 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
Re: volume broken? btrfsck fails
Yee-Ting Li yee379 at gmail.com writes: Hi, i think my btrfs volume is hosed it mounts okay, but iostat shows /dev/sdg on 100% load. dmesg shows lots of 'parent transid verify failed on x wanted y found z'. then after a while i can't read from it (access to the filesystem freezes). the machine had crashed (prob from some other process), and upon reboot i've been experience this problem since. can anyone provide any guidance in how to proceed? cheers, Yee. I am also having the same problem with a slightly different setup. In My case I cannot mount the filesystem. mount, btrfs-endio-met and kblockd/0 will all continually run until the system freezes up and requires a power cycle. I have both the kernel module and the tools checked out from git so if you have any ideas on fix's I can build them and test it out. here is some information about my setup [r...@solution ~]# uname -a Linux solution.bcig 2.6.35-0.13.rc3.git2.fc14.x86_64 #1 SMP Mon Jun 28 19:27:35 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux [r...@solution ~]# [r...@solution ~]# btrfs-show Label: store uuid: 4ba1cc6b-e12a-454a-a064-f4019312c063 Total devices 7 FS bytes used 1.15TB devid1 size 931.51GB used 415.55GB path /dev/sdb devid2 size 931.51GB used 518.50GB path /dev/sdc devid3 size 931.51GB used 342.04GB path /dev/sdd devid4 size 931.51GB used 523.54GB path /dev/sde devid5 size 465.76GB used 402.54GB path /dev/sdf devid6 size 465.76GB used 382.54GB path /dev/sdg devid7 size 465.76GB used 367.54GB path /dev/sdh Btrfs v0.19-16-g075587c-dirty [r...@solution ~]# [r...@solution ~]# tail -n 12 /var/log/messages Jul 1 04:47:03 solution kernel: parent transid verify failed on 1682196926464 wanted 285263 found 283510 Jul 1 04:47:08 solution kernel: verify_parent_transid: 9244 callbacks suppressed Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 wanted 285263 found 283510 Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 wanted 285263 found 283510 Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 wanted 285263 found 283510 Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 wanted 285263 found 283510 Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 wanted 285263 found 283510 Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 wanted 285263 found 283510 Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 wanted 285263 found 283510 Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 wanted 285263 found 283510 Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 wanted 285263 found 283510 Jul 1 04:47:08 solution kernel: parent transid verify failed on 1682196926464 wanted 285263 found 283510 [r...@solution ~]# -- 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
Re: Is there a more aggressive fixer than btrfsck?
On Mon, Jun 28, 2010 at 10:31 PM, Rodrigo E. De León Plicet rdele...@gmail.com wrote: On Mon, Jun 28, 2010 at 8:48 AM, Daniel Kozlowski dan.kozlow...@gmail.com wrote: Sean Bartell wingedtachikoma at gmail.com writes: Is there a more aggressive filesystem restorer than btrfsck? It simply gives up immediately with the following error: btrfsck: disk-io.c:739: open_ctree_fd: Assertion `!(!tree_root-node)' failed. btrfsck currently only checks whether a filesystem is consistent. It doesn't try to perform any recovery or error correction at all, so it's mostly useful to developers. Any error handling occurs while the filesystem is mounted. Is there any plan to implement this functionality. It would seem to me to be a pretty basic feature that is missing ? If Btrfs aims to be at least half of what ZFS is, then it will not impose a need for fsck at all. Read No, ZFS really doesn't need a fsck at the following URL: http://www.c0t0d0s0.org/archives/6071-No,-ZFS-really-doesnt-need-a-fsck.html Interesting idea. it would seem to me however that the functionality described in that article is more concerned with a bad transaction rather then something like a hardware failure where a block written more then 128 transactions ago is now corrupted and consiquently the entire partition is now unmountable( that is what I think i am looking at with BTRFS ) -- S.D.G. -- 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
