On Tue, Sep 25, 2012 at 11:48:34AM +0200, jakub@xxxxxxxxxxx wrote: > > On Tue, 25 Sep 2012 07:00:44 +0200 (CEST), Mikael Abrahamsson > <swmike@xxxxxxxxx> wrote: > > On Tue, 25 Sep 2012, NeilBrown wrote: > > > >> Why do you say that "the write IO errors are invisible for the > >> filesystem"? They are certainly reported in the kernel logs that you > >> should and I'm sure an application would see them if it checked return > >> status properly. > >> > >> md is behaving as designed here. It deliberately does not fail the > >> whole array, it just fails those blocks which are no longer accessible. > > > > Would you please refer to some documentation that this behaviour is > correct? I now tried to fail several disks in raid5, raid0 and raid10-near, > in case of r0 and r10n, mdadm didn't even allow me to remove more disks > than is sufficient to access all the data. In case of r5 I was able to fail > 2 out of 3, but the array was correctly marked as FAILED and couldn't be > accessed at all. I'd expect that behaviour even in my case of raid10-far. I > can't even assmenble and run it with less than required count of disks. > > > > I would imagine OP would be helped by mounting filesystem with > > "errors=remount-ro" to make sure the filesystem stops writing to the > > drives upon errors. > > Yes it's a good point. It would be be against the whole purpose of mirrored raid to put the raid in read-only mode when one disk fails. A mirrored raid should be able to still function also for writes, when this is still possible. A raid10,far with 4 disks should be able to function with 2 failed disks (in the best case). As long as all data is available and the 2 remaining functional disks are OK, they should be able to function fully normally. Of cause there needs to be warnings of the fact that 2 disks have failed. But it should not be recorded in the log for each write failed for the non-functioning disks. Best regards keld -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
