> -----Original Message----- > From: Jes Sorensen [mailto:Jes.Sorensen@xxxxxxxxxx] > Sent: Wednesday, January 18, 2012 11:09 AM > To: Kwolek, Adam > Cc: neilb@xxxxxxx; linux-raid@xxxxxxxxxxxxxxx; dledford@xxxxxxxxxx; > kay@xxxxxxxxxx; harald@xxxxxxxxxx; lpoetter@xxxxxxxxxx; > mschmidt@xxxxxxxxxx > Subject: Re: [PATCH 2/4] Add --initrd argument to mdadm > > On 01/18/12 09:13, Kwolek, Adam wrote: > > Hi, > > > > I think that '--initrd' option should have '--freeze-reshape' option > functionality for mdadm also. > > To do this e.g. proper variable (freeze_reshape in mdadm.c) should be set, > when '--initrd' option is passed in command line. > > Hi Adam, > > I don't quite know what freeze_reshape does - from the name it sounds like > an option you want to set at runtime rather than when a raid is assembled > initially? Yes, it is intended to be specified for assembly during initrd phase. It "tells" to 'grow continue' to restore array critical section only. It stops reshape at this moment to keep process safe during file system pivot when mdadm loosing fs context. Reshape should be continued later by invoking mdadm grow with '--continue' option. > > Are you proposing that we shouldn't allow reshape of an IMSM raid that is > used as the root device? We should tell to mdadm for boot device assembly to be prepared for fs pivot when reshape is in progress. We can do this by specifying 2 options in command line, but in real world "someone will forget about something", so I think '--iinitrd' can have '--freeze-reshape' functionality also /without freeze-reshape option removal for separate use when raid will not be a boot device/. As I wrote before it needs to set one variable during command line parsing in mdadm.c only. > > I am merely a bit confused here, so I am hoping you could clarify a bit. > > Thanks, > Jes Let me know if you need more clarification, or let me know if in your opinion I'm wrong. BR Adam -- 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
