On Wed, 5 Aug 2015 14:42:21 -0700 Shaohua Li <shli@xxxxxx> wrote: > On Wed, Aug 05, 2015 at 02:13:51PM +1000, NeilBrown wrote: > > On Wed, 29 Jul 2015 17:38:47 -0700 Shaohua Li <shli@xxxxxx> wrote: > > > > > If cache(log) support is enabled, don't allow resize/reshape in current > > > stage. In the future, we can flush all data from cache(log) to raid > > > before resize/reshape and then allow resize/reshape. > > > > Just to be on the safe side, you could probably add code to refuse to > > start an array that is in the middle of a reshape and also have a log > > configured. > ok > > > I think it makes sense to plan ahead a little and make sure we can > > handle a cache on a reshaping array properly. > > > > If the log metadata block includes a before/after flag for each stripe, > > which recorded whether the stripe was "before" or "after" > > reshape_position when it was written, then when recovering the log we > > can check if the given addresses are still on that side. If they are, > > just recover using the appropriate geometry info from the superblock. > > If not, then reshape has passed over that stripe and it must now be > > fully up-to-date on the RAID so the data in the log can be discarded. > > > > There may be some details I missed, but I think it is worth thinking > > through properly. I don't expect the code to handle this straight > > away, but we need a clear plan to be sure there is sufficient > > information stored in the log. > > Just adding a flag is enough? Sounds there is no way to avoid the write > hole issue if the array is reshapping. The data stored in log is valid, > but if a reshape runs, we can't guarantee the parity is valid. When a region of the array is reshaped, the current data is read (if not already in the stripe cache), then written out to a location on disk which is not currently in use, and then the superblock is updated to record that the new area should be used and the old area is no longer relevant. So we have atomic updates from 'old' to 'new'. There is no write-hole issue for these writes. So if a particular address in the array was in the 'old' section when data was written to the log, and if on restart those addresses are in the 'new' section, then we can be sure that the data, including parity, was completely written to the new section - so the data in the log is not needed. So if we just add a before/after flag to entries in the log then we can safe recovery around a reshape. When reading the log on restart in some data is marked as being in the 'old' section but the address now maps to the 'new' section, then we safely ignore that data. Thanks, NeilBrown -- 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
