On 06/04/2012 09:43 AM, Maxim Mikheev wrote: > Hi Liu, > > thanks for advice. I tried it before btrfsck. results are here: > max@s0:~$ sudo mount /tank -o recovery > [sudo] password for max: > mount: wrong fs type, bad option, bad superblock on /dev/sdf, > missing codepage or helper program, or other error > In some cases useful info is found in syslog - try > dmesg | tail or so > > max@s0:~$ sudo mount -o recovery /tank > mount: wrong fs type, bad option, bad superblock on /dev/sdf, > missing codepage or helper program, or other error > In some cases useful info is found in syslog - try > dmesg | tail or so > Two possible ways: 1) I noticed that your btrfs had 5 partitions in all: mkfs.btrfs /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf Can you try to mount other disk partitions instead by hand, like: mount /dev/sdb /tank mount /dev/sdc /tank mount /dev/sdd /tank mount /dev/sde /tank mount /dev/sdf /tank 2) use btrfs's scrub to resort to metadata backups created by RAID1. thanks, liubo > dmesg after boot before mount -o recovery: > [ 51.829352] parent transid verify failed on 5468060241920 wanted 9096 > found 7621 > [ 51.841153] parent transid verify failed on 5468060241920 wanted 9096 > found 7621 > [ 51.841603] btrfs read error corrected: ino 1 off 5468060241920 (dev > /dev/sdb sector 2143292648) > [ 51.841610] Failed to read block groups: -5 > [ 51.848057] btrfs: open_ctree failed > .............................. > dmesg after both mounts: > > [ 123.687773] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 5 > transid 9096 /dev/sdf > [ 123.733678] btrfs: use lzo compression > [ 123.733683] btrfs: enabling auto recovery > [ 123.733686] btrfs: disk space caching is enabled > [ 131.699910] parent transid verify failed on 5468060241920 wanted 9096 > found 7621 > [ 131.714018] parent transid verify failed on 5468060241920 wanted 9096 > found 7621 > [ 131.715059] btrfs read error corrected: ino 1 off 5468060241920 (dev > /dev/sdb sector 2143292648) > [ 131.715072] Failed to read block groups: -5 > [ 131.727176] btrfs: open_ctree failed > [ 161.697873] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 5 > transid 9096 /dev/sdf > [ 161.746345] btrfs: use lzo compression > [ 161.746354] btrfs: enabling auto recovery > [ 161.746358] btrfs: disk space caching is enabled > [ 169.720823] parent transid verify failed on 5468060241920 wanted 9096 > found 7621 > [ 169.732048] parent transid verify failed on 5468060241920 wanted 9096 > found 7621 > [ 169.732611] btrfs read error corrected: ino 1 off 5468060241920 (dev > /dev/sdb sector 2143292648) > [ 169.732623] Failed to read block groups: -5 > [ 169.743437] btrfs: open_ctree failed > > So It does not work. I have seen in some posts command: > > sudo mount -s 2 -o recovery /tank > Should I try it? > > Please help me, I need to get this data ASAP. > > Regards, > Max > > On 06/03/2012 09:22 PM, Liu Bo wrote: >> On 06/02/2012 09:43 PM, Maxim Mikheev wrote: >> >>> Repair was not helpful. >>> Is any other ways to get access to data? >>> >>> Please help.... >>> >> >> Hi Maxim, >> >> Besides btrfsck --repair, we also have a recovery mount option to deal >> with your situation, >> maybe you can try mount xxx -o recovery and see if it helps? >> >> >> thanks, >> liubo >> >>> On 05/30/2012 11:15 PM, Michael K wrote: >>>> Let it run to completion. There is little you can do other than hope >>>> and wait. >>>> >>>> On May 30, 2012 9:02 PM, "Maxim Mikheev"<mikhmv@xxxxxxxxx >>>> <mailto:mikhmv@xxxxxxxxx>> wrote: >>>> >>>> btrfsck --repair running already for 26 hours. >>>> >>>> Is it have sense to wait more? >>>> >>>> Thanks >>>> >>>> On 05/29/2012 07:36 PM, cwillu wrote: >>>> >>>> On Tue, May 29, 2012 at 5:24 PM, Maxim >>>> Mikheev<mikhmv@xxxxxxxxx<mailto:mikhmv@xxxxxxxxx>> wrote: >>>> >>>> Thank you for your answer. >>>> >>>> >>>> The system kernel was and now: >>>> >>>> Linux s0 3.4.0-030400-generic #201205210521 SMP Mon May 21 >>>> 09:22:02 UTC 2012 >>>> x86_64 x86_64 x86_64 GNU/Linux >>>> >>>> the raid was created by: >>>> mkfs.btrfs /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf >>>> >>>> Disk are connected through RocketRaid 2670. >>>> >>>> for mounting I used line in fstab: >>>> UUID=c9776e19-37eb-4f9c-bd6b-04e8dde97682 /tank >>>> btrfs >>>> defaults,compress=lzo 0 1 >>>> >>>> On machine was running several Virtual machines. Only one >>>> was actively using >>>> disks. >>>> >>>> VM has active several threads: >>>> 1. 2 threads reading big files (50GB each) >>>> 2. reading from 50 files and writing one big file >>>> 3. The kernel panic happens when I run another program >>>> with 30 threads of >>>> reading/writing of small files. >>>> >>>> Virtual Machine accessed to underline btrfs through 9-p >>>> file system which >>>> actively used xattr. >>>> >>>> After reboot system was in this stage. >>>> >>>> I hope that btrfsck --repair will not make it worse, It is >>>> now running. >>>> >>>> **twitch** >>>> >>>> Well, I also hope it won't make it worse. Do not cancel it >>>> now, let >>>> it finish (aborting it will make things worse), but I suggest >>>> waiting >>>> until a few more people have weighed in before attempting >>>> anything >>>> beyond that. >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe >>>> linux-btrfs" in >>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>> <mailto:majordomo@xxxxxxxxxxxxxxx> >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe >>> linux-btrfs" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
