On Mon, May 7, 2012 at 5:46 PM, Helmut Hullen <Hullen@xxxxxxxxxxx> wrote:
> For some months I run btrfs unter kernel 3.2.5 and 3.2.9, without
> problems.
>
> Yesterday I compiled kernel 3.3.4, and this morning I started the
> machine with this kernel. There may be some ugly problems.
> Data, RAID0: total=5.29TB, used=4.29TB
Raid0? Yaiks!
> System, RAID1: total=8.00MB, used=352.00KB
> System: total=4.00MB, used=0.00
> Metadata, RAID1: total=149.00GB, used=5.00GB
>
> Label: 'MMedia' uuid: 9adfdc84-0fbe-431b-bcb1-cabb6a915e91
> Total devices 3 FS bytes used 4.29TB
> devid 3 size 2.73TB used 1.98TB path /dev/sdi1
> devid 2 size 2.73TB used 1.94TB path /dev/sdf1
> devid 1 size 1.82TB used 1.63TB path /dev/sdc1
>
> May 7 06:55:26 Arktur kernel: ata5: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen
> May 7 06:55:26 Arktur kernel: ata5: SError: { PHYRdyChg }
> May 7 06:55:26 Arktur kernel: ata5: hard resetting link
> May 7 06:55:31 Arktur kernel: ata5: COMRESET failed (errno=-19)
> May 7 06:55:31 Arktur kernel: ata5: reset failed (errno=-19), retrying in 6 secs
> May 7 07:15:19 Arktur kernel: sd 5:0:0:0: rejecting I/O to offline device
> May 7 07:15:19 Arktur kernel: end_request: I/O error, dev sdf, sector 0
> May 7 07:15:19 Arktur kernel: sd 5:0:0:0: rejecting I/O to offline device
> May 7 07:15:19 Arktur kernel: lost page write due to I/O error on sdf1
That looks like a bad disk to me, and it shouldn't be related to ther
kernel version you use.
Your best chance might be:
- unmount the fs
- get another disk to replace /dev/sdf, copy the content over with
dd_rescue. Ata resets can be a PITA, so you might be better of by
moving the failed disk to a usb external adapter, and du some creative
combination of plug-unplug and selectively skip bad sectors manually
(by passing "-s" to dd_rescue).
- reboot, with the bad disk unplugged
- (optional) run "btrfs filesystem scrub" (you might need to build
btrfs-progs manually from git source). or simply read the entire fs
(e.g. using tar to /dev/null, or whatever). It should check the
checksum of all files and print out which files are damaged (either in
stdout or syslog).
I don't think there's anything you can do to recover the damaged files
(other than restore from backup), but at least you know which files
are NOT damaged.
--
Fajar
--
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
