Thanks a lot for your replies. 2009/8/23 NeilBrown <neilb@xxxxxxx>: > On Mon, August 24, 2009 8:39 am, Lucian Șandor wrote: >> battlecruiser:~ # zcat /var/log/messages-20090823.gz | grep md >> [...] >> Aug 23 07:34:59 battlecruiser kernel: md: couldn't update array info. -16 >> >> (This last one appears to be the moment when it goes past 100%.) > > -16 is EBUSY. It appears something tried to reshape the array again? > Maybe you tried to repeat the --grow command?? Whatever it was, it wasn't > allowed to proceed because the array was busy reshaping. > So it is harmless. > I didn't try anything. As I said, I believe it could be the moment when it goes over 100%. It happens at 7:34. I think it is so, because my initial message, at 7:49, corresponds to 106%. Good to know it's harmless, maybe it's a side effect of the bug I already ran into. > What "persistent error regarding the number of blocks" are you referring > to? Except for the transient problems with mdstat, everything looks > good. > Post-reshape, I still the same number of blocks, which apparently was incorrect. I also have the failure on "array status" on mdadm --examine. >> I am pondering whether to extend the file system. > > I should be safe to do that. > I am running a sync_action=check operation right now and it doesn't say anything bad. (Not that I have any idea what to see as bad signs.) Despite the odd output, your program does a great job in preserving data integrity. Thanks again, Lucian -- 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
