Hello Neil, On 06/25/2014 03:03 AM, NeilBrown wrote: [...] >> >> After waiting a couple of min, stopping again md126 worked: >> >> [ 1835.755661] md: md126 stopped. >> >> Is this expected ? > > No overly surprising. > > This is probably caused by udev, or something udev runs, opening /dev/md126 > after it has been stopped. This has the effect of creating an empty inactive > array. > e.g. > Why opening /dev/md126 after it's been stopped didn't fail ? Also why doing 'mdadm --stop /dev/md126' several times reports that the array was stopped each time ? > mknod /dev/test b 9 57 > < /dev/test > > will make /sys/block/md57 appear. > > It is a bit untidy, but shouldn't cause problems. > Another 'inconsistent' state I noticed is when a new array is created. There's a time window when /sys//block/md127/md exists but the contained disk (dev-sda1 dev-sdb1, for example) are not present in that directory. This state (as the previous one) confuses my tool that is listening udev events in order to register all block devices present in the system. So I am wondering how I should deal with this 'transition' states and how can detect them in a reliable way ? Thanks. -- 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
