<div dir="ltr">Ben,<div><br></div><div>I'd need your ack on this one.</div><div><br></div><div>Best regards,</div><div>Christophe Varoqui</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 15, 2014 at 9:21 PM, Stewart, Sean <span dir="ltr"><<a href="mailto:Sean.Stewart@netapp.com" target="_blank">Sean.Stewart@netapp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ping...  Any additional comments or suggestions for this patch?<br>
Bumping in case it got lost in the backlog. :)<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, 2014-04-11 at 17:01 +0000, Stewart, Sean wrote:<br>
> On Fri, 2014-04-11 at 17:03 +0100, Bryn M. Reeves wrote:<br>
> > On Fri, Mar 28, 2014 at 09:01:14PM +0000, Stewart, Sean wrote:<br>
> > > When a system is booted to the SAN, a condition can occur where one<br>
> > > user friendly name is given to a disk during boot, but multipathd tries<br>
> > > to allocate a different one after boot. If the second alias is already<br>
> > > used by another device, multipathd can't rename it. Multipathd then has<br>
> > > incorrect information about the alias/wwid relationships, which can<br>
> > > result in paths being added to the wrong map.<br>
> ><br>
> > This should only happen if the initramfs and root file system have<br>
> > inconsistent multipath configurations (either multipath.conf or bindings<br>
> > / wwids file mismatched). That's not really a valid configuration for<br>
> > the system to be in and leads to the type of problems you describe.<br>
><br>
> That is true that it only happens if they are out of sync.  We tried<br>
> remaking the initramfs to fix the problem, but it didn't help.<br>
> ><br>
> > > This patch works around this problem by first trying to use the alias<br>
> > > already bound to a device during boot.  If the bindings file has that<br>
> > > alias bound to a different device, it'll auto generate a new alias to<br>
> > > rename it to.<br>
> ><br>
> > To be honest I'd prefer to see this cause an error. These types of<br>
> > configurations currently run the risk of silent data corruption - I'd<br>
> > much rather deal with a system that refuses to boot due to an out of<br>
> > date initramfs image than one that quietly remaps paths in unexpected<br>
> > ways.<br>
><br>
> The issue, though, is that the system does not refuse to boot.  In the<br>
> case we saw, it booted anyway, our QA engineer ran a test, and it ended<br>
> with a data corruption.  A user could perform a fresh installation,<br>
> map<br>
> new luns, reboot, and without any way of realizing it have essentially a<br>
> ticking time bomb on their hands, ready to go off as soon as there's a<br>
> blip in the SAN.<br>
<br>
</div></div></blockquote></div><br></div>