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.
.................................
Backups, you everytime need them when you don't have.....
We was urgently need extra space and planed to buy new disks soon.....
On 05/29/2012 07:11 PM, cwillu wrote:
I can't help much at the moment, but the following will help sort things out:
Can you provide as much detail as possible about how things were
configured at the time of the failure? Raid levels used, kernel
versions at the time of the failure, how the disks are connected,
general description of the activity on the disk and the nature of its
contents (all large files? rootfs? mail spools?) What you were
thinking at the time you decided that you couldn't afford backups? As
much detail as possible on what all you've tried since the failure to
recover things?
It's likely the data is fine (if currently inaccessible), but
obviously things are in a fragile state, and the important thing right
now is to not make things worse: a recoverable situation may otherwise
turn into an irrecoverable one.
--
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
