Bug#396582: Some additional info

[Dan Pascu]

martin f krafft wrote: also sprach Dan Pascu <[EMAIL PROTECTED]> [2006.11.02.0946 +0100]: Yes. In my case, if I fail a drive, it is still there in a failed state, but if I then stop the raid array, when it's restarted, the failed drive is no longer there, as if it was removed meanwhile, only that I never issued the remove command. And when the array starts, it shows that it started degraded with only 1 out of 2 drives. I managed to reproduce it; you just have to write to the array after fail and before stop: piper:~# mdadm -Cl1 -n2 /dev/md99 /dev/sd[ef]1 piper:~# mdadm --fail /dev/md99 /dev/sde1 mdadm: set /dev/sde1 faulty in /dev/md99 piper:~# dd if=/dev/zero of=/dev/md99 [...] 65667072 bytes (66 MB) copied, 2.57956 seconds, 25.5 MB/s piper:~# mdadm -Ss mdadm: stopped /dev/md99 piper:~# mdadm -As mdadm: /dev/md/99 has been started with 1 drive (out of 2). mdadm: /dev/md/99 already active, cannot restart it! mdadm: /dev/md/99 already active, cannot restart it! [...] Martin, I'm pretty sure that writing to the failed array is not the cause of the problem, but more like a trigger. In my case I have never wrote to the failed arrays during my testing. There was an array I have never wrote anything to, and in another case there was an array I only wrote to while it was complete (before failing it). But I'm glad you were able to at least see the problem I'm experiencing. One thing that intrigues me is why in my case when failing a drive and stopping the array, after restarting it, the failed drive was already removed (even though I never removed it myself) and the arrays started degraded with 1 drive out of 2, and in your case the array started with the failed drive included and reported that it started with 2 drives. -- Dan