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 <chris.ma...@oracle.com> wrote: > On Wed, Feb 29, 2012 at 05:11:24PM -0600, Travis Shivers wrote: >> 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, >> I have the array being mirrored so that there are two copies of a file >> 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 >> 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=N82E16816132029 >> >> The corruption was unexpected. I am not entirely sure what caused it, >> but a few days before the corruption, there were several power >> outages. I do not think that the problem is with the actual hard drive >> 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. Which kernel were you running when > you had the power outages? > > I'm testing out the patch to skip the extent allocation tree at mount. > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
