Suman,
> To simulate the failure, I detached one of the drives from the system.
> After that, I see no sign of a problem except for these errors:
Are you physically pulling out the device ? I wonder if lsblk or blkid
shows the error ? reporting device missing logic is in the progs (so
have that latest) and it works provided user script such as blkid/lsblk
also reports the problem. OR for soft-detach tests you could use
devmgt at http://github.com/anajain/devmgt
Also I am trying to get the device management framework for the btrfs
with a more better device management and reporting.
Thanks, Anand
On 10/13/14 07:50, Suman C wrote:
Hi,
I am testing some disk failure scenarios in a 2 drive raid1 mirror.
They are 4GB each, virtual SATA drives inside virtualbox.
To simulate the failure, I detached one of the drives from the system.
After that, I see no sign of a problem except for these errors:
Oct 12 15:37:14 rock-dev kernel: btrfs: bdev /dev/sdb errs: wr 0, rd
0, flush 1, corrupt 0, gen 0
Oct 12 15:37:14 rock-dev kernel: lost page write due to I/O error on /dev/sdb
/dev/sdb is gone from the system, but btrfs fi show still lists it.
Label: raid1pool uuid: 4e5d8b43-1d34-4672-8057-99c51649b7c6
Total devices 2 FS bytes used 1.46GiB
devid 1 size 4.00GiB used 2.45GiB path /dev/sdb
devid 2 size 4.00GiB used 2.43GiB path /dev/sdc
I am able to read and write just fine, but do see the above errors in dmesg.
What is the best way to find out that one of the drives has gone bad?
Suman
--
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
--
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
