On Mon, Aug 29, 2011 at 7:20 PM, NeilBrown <neilb@xxxxxxx> wrote: >> Anna rightly points out that this could probably be safely made >> bigger. As it stands this applies to too broad an array of disks. I >> think a happy medium (until we can nail down the forward compatibility >> of older oroms, v8 in this case) is to detect the case where the disk >> is being activated for rebuild and if it is at least as large as one >> of the existing members truncate the reserved region to the same size >> as the other member. That way we are at least compatible with >> whatever agent created the array in the first instance. >> > > I think you are saying that I can go ahead and apply this patch, but that it > might get improved upon in the future .... I hope that is right ? Yes, this may have corrected things too far in the other direction, but is less surprising than what we had before. >> But this also comes back to the problem of duplicating the array >> configuration. It becomes difficult to make things the same size >> unless the orom version (reserved region layout) is specified. > > Yes, that is occasionally a serious problem. As metadata becomes more > flexible it become harder to reproduce exact configuration. > > Maybe I need a --no-default option to --create to ensure no defaults are used. > Then some sort of generic > --config-param foo=bar > which creates a dictionary of foo=bar assignments which are used by the > metadata to fill in any detail that they would normally fill from defaults. > > Sounds a bit heavy-weight though... I think having a metadata dump facility covers most the need for duplicating a configuration. -- 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
