On Tuesday November 12, bernd-schubert@web.de wrote: > Hello Neil, > > thanks for your answer. > > > > Well, the 'delaying resync ...' messages are easy to understand, but are > > > they related to the 'resync aborted' messages ? At least the /proc/mdstat > > > looks fine. > > > > It looks fine ... but the arrays probably aren't in sync. > > How can we force the syncing ? You could try mdadm --readwrite /dev/md? that should probably do it. > > > The 'resync aborted' is caused either by IO errors, which should show > > up in dmesg, or the resync threads being signaled, or by the array > > being switched into readonly mode. > > Hmm, I think the dmesg-output doesn't show IO-errors and since we write to the > disks (our home-partition is on it), it shouldn't be readonly, either. > Which only leaves some process sending a SIGKILL to the raid5syncd thread... is that at all possible? > > > > I'm curious about this raidautorun which said: > > md: raidautorun(pid 89) used obsolete MD ioctl, upgrade your software to > > use new ictls > > > > That appears to be part of mkinitrd. What distribution are you > > running? What version? What version of mkinitrd? > > > > This is a Suse-7.3 system, but with vanilla kernel and without initrd-support. > I guess it comes from the Suse-start-up-scripts, that try to enable the raid, > though it was already enabled by the kernel. > The raidautorun-binary comes from the Suse-raidtools package (version 0.9), is > there an upgraded version available (I found only patched debian packages, > but no general tgz-files) ? Ok, I managed to find it. It just does ioctl(, RAID_AUTORUN) on /dev/md0 which just prints out a bad-ioctl error message. It isn't implicated at all. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
