Takahiro Yasui [tyasui@xxxxxxxxxx] wrote: > >> I haven't checked the contents of log disk, but I guess we can't > >> differentiate these cases from log disks. > > > > There were plans to add a new region state to make sure that all the > > mirror legs have same data after a "crash". Currently your best bet is a > > complete resync after a crash! > > Please let me clarify this. There are two legs and system crash happens. > Then, how can we resync? We have only one leg (secondary) after boot. > When we use "mirror", we expect the last device to contain valid data, > don't we? I was actually referring to a problem that I mentioned in a DM/LVM meeting. Mikulas posted it here and there were some discussions. http://thread.gmane.org/gmane.linux.kernel.device-mapper.devel/5392 If I remember, the proposed solution would add another state bit. If it is implemented, then we can use that information to differentiate the cases you mentioned. Essentially, if there are only 'dirty' regions, we can safely use the secondary. On the other hand, if th log has some 'out of sync' regions, then we can't use the secondary. You can ignore my reference to "complete resynchronization". I was referring to an existing problem with system crashes! > > Or just have LVM meta data that records a device failure. Suspend writes > > [for any kind of leg] and record device failure in the LVM meta data and > > restart writes. This requires LVM meta data change though! > > Do you mean that write I/Os need to be blocked when the secondary leg fails > in order to update LVM meta data by lvm commands called by dmeventd? Yes, that is correct. We need to stop write I/O for any leg failure if we chose LVM meta data method. Thanks, Malahal. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
