On 12.09.2014 12:47, Hugo Mills wrote:
I've done this before, by accident (pulled the wrong drive, reinserted it). You can fix it by running a scrub on the device (btrfs scrub start /dev/ice, I think).
I'd like to remind everyone that btrfs has weak checksums. It may be good for correcting an occasional error, but I wouldn't trust it to correct larger amounts of data.
Additionally, nocow files are not checksummed. They will not be corrected and may return good data or random garbage, depending on which mirror is accessed.
Below is a test I did some time ago, demonstrating the problem with nocow files:
#!/bin/sh MOUNT_DIR=mnt DISK1=d1 DISK2=d2 SIZE=2G # create raid1 FS mkdir $MOUNT_DIR truncate --size $SIZE $DISK1 truncate --size $SIZE $DISK2 L1=$(losetup --show -f $DISK1) L2=$(losetup --show -f $DISK2) mkfs.btrfs -d raid1 -m raid1 $L1 $L2 mount $L1 $MOUNT_DIR # enable NOCOW chattr +C $MOUNT_DIR umount $MOUNT_DIR # fail the second drive losetup -d $L2 mount $L1 $MOUNT_DIR -odegraded # file must be large enough to not get embedded inside metadata perl -e 'print "Test OK.\n"x4096' >$MOUNT_DIR/testfile umount $MOUNT_DIR # reattach the second drive L2=$(losetup --show -f $DISK2) mount $L1 $MOUNT_DIR # let's see what we get - correct data or garbage? cat $MOUNT_DIR/testfile # clean up umount $MOUNT_DIR losetup -d $L1 losetup -d $L2 rm $DISK1 $DISK2 rmdir $MOUNT_DIR -- 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
