On Wed, 21 Sep 2011 07:31:48 +0000 "Kwolek, Adam" <adam.kwolek@xxxxxxxxx> wrote: > > > > -----Original Message----- > > From: NeilBrown [mailto:neilb@xxxxxxx] > > Sent: Wednesday, September 21, 2011 4:34 AM > > To: Kwolek, Adam > > Cc: linux-raid@xxxxxxxxxxxxxxx; Ciechanowski, Ed; Labun, Marcin > > Subject: Re: [PATCH 13/14] Check if md allows to control reshape > > > > On Fri, 16 Sep 2011 13:55:25 +0200 Adam Kwolek <adam.kwolek@xxxxxxxxx> > > wrote: > > > > > It can happen that there is no mdadm in memory and 'max' was already > > > set to sync_max. Such array cannot be put under check pointing control > > > again. > > > > Again I don't understand what you are trying to guard against. > > If resync_max is 'max', then the kernel is allowed to fun reshape to > > completion without any help from mdadm. If mdadm needs to monitor > > things it always sets resync_max to a smaller value. > > > > Confused. > > In my opinion running reshape continuation on array that is allowed to freely reshape to the end > is race condition (another mdadm or user via sysfs manage this array already). > We can tell nothing about restart point (read from metadata) when md runs with reshape already. > I think we should not allow to attach mdadm to such reshape process. > > I think this guard is required. > I see what your point is now. I was just a bit confused by the message that is printed which seems to say something different. If we need to guard something here, we need to guard against a lot more than just sync_max == "max". We need to guard against another mdadm process monitoring the array (the extra .pid file I mentioned) and also if sync_max has any value larger than what we would expect from the metadata. So a test that rejects an attempt to continue reshape on an array where sync_max is not the correct value makes sense. Just testing for "max" doesn't. Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
