[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help with data recovering

btrfsck --repair running already for 26 hours.

Is it have sense to wait more?


On 05/29/2012 07:36 PM, cwillu wrote:
On Tue, May 29, 2012 at 5:24 PM, Maxim Mikheev<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

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.

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
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

Add to Google Powered by Linux