2006/3/7, Neil Brown <neilb@xxxxxxx>: > Thank you for your thoughts. You welcome ! [...] > So an upsize migration from any of these level to any other could be > done within the raid6 code providing the raid6 code could cope with an > array where the Q block was not present (which is often the case in a > degraded array anyway). > > So to perform an generic upsize migration, I would: > switch to raid6 mode with appropriate layout > perform the growth within raid6 > switch back to more appropriate module. > You seem to be really keen on raid6 for these topics ; I may have a closer look on this layer to really understand why you wish to rely on this for these issues... Can it really be possible to teach raid6 how to handle such different layouts ? > For stable migration you really to need to log to a separate device. > This would be slow, but not impossible. It could be done with the > 'grow' function in raid6 and so the above approach would still work. Well, I think so. I would really like to work on such things, including the use of an external drive (external WRT raid), to harden such things... > The only complication comes with raid10. Here, I shall agree... [...] > NeilBrown > BTW, I could not find any kind of git tree nor svn containing experimental works on raid, (f.e. including your raid5 reshape code...). Does this exist ? I would also be interrested in hardening mdadm for your raid5 reshape patch (i.e. fixing the vulnerability issue at the beginning of the reshape). Is http://www.cse.unsw.edu.au/~neilb/source/mdadm/ the only place where you store mdadm versions ? - 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
