Re: Help with data recovering

[Maxim Mikheev <mikhmv@gmail.com>]

I forgot to add.
Btrfs-tools was build from:
git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git



On 05/29/2012 07:24 PM, Maxim Mikheev 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.
>
> .................................
> 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.