On Thu, Oct 18, 2012 at 12:29:59PM +1100, NeilBrown wrote: > On Thu, 18 Oct 2012 09:17:35 +0800 Shaohua Li <shli@xxxxxxxxxx> wrote: > > > > > Neil, > > > > any further comments on this? This is a usable feature, I hope we can have some > > > > agreements. > > > > > > You still haven't answered my main question, which possibly means I haven't > > > asked it very clearly. > > > > > > You are saying that this new behaviour should not be the default and I think > > > I agree. > > > So the question is: how it is selected? > > > > > > You cannot expect the user to explicitly enable it any time a resync or > > > recovery starts that should use this new feature. You must have some > > > automatic, or semi-automatic, way for the feature to be activated, otherwise > > > it will never be used. > > > > > > I'm not asking "when should the feature be used" - you've answered that > > > question a few time and it really isn't an issue. > > > The question it "What it the exact process by which the feature is turned on > > > for any particular resync or recovery?" > > > > So you worried about users don't know how to correctly select the feature. An > > experienced user knows this, the usage scenario I mentioned describes how to do > > the decision. For example, a resync after system crash should enable the > > feature. I admit an inexperienced user doesn't know how to select it, but this > > isn't a big problem to me. There are a lot of tunables in the kernel (even MD), > > which can significantly impact kernel behavior. These tunables are just for > > experienced users. > > > > Thanks, > > Shaohua > > > You still aren't answering my question. > > What exactly, precisely, specifically, will an "experienced user" do? Set something to a sysfs entry to enable the feature (like my RFC patch does to have a new sysfs entry for the feature), and readd disk. resync then does 'only write mismatch data'. Is this what you asked? -- 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
