Mikulas Patocka [mpatocka@xxxxxxxxxx] wrote: > > > > Imagine this scenario: > > > * secondary leg fails > > > * write fails on the secondaty leg and succeeds on the primary leg > > > and is successfully complete > > > * the computer crashes > > > * after a reboot, the primary leg is inaccessible and the secondary leg is > > > back online --- now raid1 would be returning stale data. > > > > The software can detect this case. We can fail this completely or use > > the data from the secondary that could be "stale" with help from admin. > > Let us call this method 1. > > You can't detect it because the computer crashed *before* you write the > information that the secondary leg failed to the metadata. > > So, after a reboot, you can't tell if any mirror leg failed some requests > before the crash. My definition of 'primary' is the first leg. Now on, I will use "first leg" to avoid confusion. On a reboot, LVM can find if its first leg is missing. If it is missing, it can ask the admin whether to use the 'second' leg or not. When I said, "software" can detect, I really meant that LVM can detect that the "first leg" is missing. > > > If we hold the bios if the secondary leg fails (as the patch does), one of > > > these two scenarios happen: > > > > > > * secondary leg fails > > > * write succeeds on the primary leg and is held > > > * the computer crashes > > > * after a reboot, the primary leg is inaccessible and the secondary leg is > > > back online --- but we haven't completed the write, so the transaction > > > wasn't reported as committed > > > > > > or > > > > > > * secondary leg fails > > > * write succeeds on the primary leg and is held > > > * dmeventd removes the secondary leg and the write succeeds > > > * the computer crashes > > > * after a reboot, the primary leg is inaccessible, the secondary leg was > > > already removed by dmeventd, so the array is considered inaccessible. So > > > it doesn't work but at least it doesn't revert already committed > > > transaction. > > > > How is this latter case (it doesn't need a crash anyway) > > different/better from the case where we detect that 'primary' is missing > > and ask admin if he wants to use the data on the secondary or not. At > > least, the admin has a choice with "method 1" and this doesn't have that > > choice. > > If you ask the admin always if primary leg failed and wait for his action, > you lose fault-tolerance --- the computer would wait until the admin does > an action. Well, we are talking one time admin help at reboot [actually activation time] if and only if the "state of the mirror" changed during reboot! This is not applicable at run time. Most of the time, dmeventd will have a chance to change the mirror to linear anyway. > The requirements are: > * if one of legs fail or log fails, you must automatically continue > without human intervention This is satisfied. I was saying for the admin input only at reboot time. What happens if first leg fails now? I think, activation fails and needs to specify "--partial" or so. > * if both legs fail, you must shut it down and not pretend that something > was written when it wasn't (this would break durability requirement of > transactions). True. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
