I was running a fairly old version of the kernel:
Linux server 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux

On Wed, Feb 29, 2012 at 5:44 PM, Chris Mason [off-list ref] w=
rote:

On Wed, Feb 29, 2012 at 05:11:24PM -0600, Travis Shivers wrote:

quoted

Thank you all for helping. My btrfs array consists of 4 disks: 2 (2
TB) disks and 2(500 GB) disks. Since I have disks of different sizes=

,

quoted

I have the array being mirrored so that there are two copies of a fi=

le

quoted

on two separate disks. The data and metadata are mirrored.

I originally made the array by using this command:

# mkfs.btrfs -m raid1 -d raid1 /dev/sd[abcd]
(The drives were originally those letters)


All of the disks sit in an external 4 bay ESATA enclosure going into=

 a

quoted

PCI-E RAID card set up as JBOD, so I can use btrfs' software
mirroring. This is the enclosure that I have:
http://www.newegg.com/Product/Product.aspx?Item=3DN82E16816132029

The corruption was unexpected. I am not entirely sure what caused it=

,

quoted

but a few days before the corruption, there were several power
outages. I do not think that the problem is with the actual hard dri=

ve

quoted

hardware since they are fairly new (6 months old) and they pass all
SMART tests. After a reboot, the btrfs array refused to mount and
started giving off errors. I do weekly scrubs, balances, and
defragmentation.

Ok, all of this should have worked. =A0Which kernel were you running =

when

you had the power outages?

I'm testing out the patch to skip the extent allocation tree at mount=

=2E

That will be the easiest way to get to the data (readonly, but it'll
work).

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html