On Aug 18, 2013, at 4:35 PM, Stuart Pook <[email protected]> wrote: >> >> You first shrank a 2TB btrfs file system on dmcrypt device to 590GB. >> But then you didn't resize the dm device or the partition? > > no, I had no need to resize the dm device or partition.
OK well it's unusual to resize a file system and then not resize the containing block device. I don't know if Btrfs cares about this or not. > > I ran a badblocks scan on the raw device (not the luks device) and didn't get > any errors. badblocks will depend on the drive determining a persistent read failure with a sector, and timing out before the SCSI block layer times out. Since the linux SCSI driver time out is 30 seconds, and most consumer drive ECT is 120 seconds, the bus is reset before the drive has a chance to report a bad sector. So I think you're better off using smartctl -l long tests to find bad sectors on a disk. Further a smartctl -x may show SATA Phy Event Counters, which should have 0's or very low numbers and if not then that's also an indicator of hardware problems. > The data was written to the WD-Blue (640Gb) disk and then copied off it. The > only errors I saw concerned the WB-Blue. If the errors were data corruption > on writing or reading the WD-Blue then I would have thought that the > checksums would have told me that there was something wrong. btrfs didn't > give me an IO error until I started to read the files when the data was on a > final disk. How does Btrfs know there's been a failure during write if the hardware hasn't detected it? Btrfs doesn't re-read everything it just wrote to the drive to confirm it was written correctly. It assumes it was unless there's a hardware error. It wouldn't know this until a Btrfs scrub is done on the written drive. What I can't tell you is how Btrfs behaves and if it behaves correctly, when writing data to hardware having transient errors. I don't know what it does when the hardware reports the error, but presumably if the hardware doesn't report an error Btrfs can't do anything about that except on the next read or scrub. > > Just to be clear. This is the series of btrfs replace I did: > > backups : HD204UI -> WD-Blue > /mnt : WD-Black -> HD204UI > backups : WD-Blue -> WD-Black > > I guess that my backups were corrupted was they were written to or read from > the WD-Blue. Wouldn't the checksums have detected this problem before the > data was written to the WD-Black? When you first encountered the btrfs reported csum errors, what operation was occurring? > >> There's only so much software can do to overcome blatant hardware problems. > > I was hoping to be informed of them Well you were informed of them in dmesg, by virtue of the controller having problems talking to a SATA rev 2 drive at rev 2 speed, with a negotiated fallback to rev 1 speed. > >> But, it seems unlikely such a high percent of errors would go >> undetected to result in so many uncorrectable errors, so there may be >> user error here along with a bug. > > I'm not sure how I could have done it better. Does "btrfs replace" check that > the data is correctly written to the new disk before it is removed from the > old disk? That's a valid question. Hopefully someone more knowledgable can answer what the expected error handling behavior is supposed to be. > Should I have used the 2 disks to make a RAID-1 and then done a scrub before > removing the old disk? Good question. Possibly it's best practices to use btrfs replace with an existing raid1, rather than using it as a way to move a single copy of data from one disk to another. I think you'd have been better off using btrfs send and receive for this operation. A full dmesg might also be enlightening even if it is really long. Just put it in its own email without comment. I think pasting it out of forum is less preferred. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
