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
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
