<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-17 18:34 GMT+02:00 Andrew J. Hobbs <span dir="ltr"><<a href="mailto:ajhobbs@desu.edu" target="_blank">ajhobbs@desu.edu</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In your case, with 4 servers and a '-c 2', you can survive a single failure _at a time_ down</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">... </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 Due to zoning, no machine has more than a single copy of any particular vdi block</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">.... <br>
</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">No more so than Raid 6 makes you immune to drive loss, simply immune to up to 2 failed drives.<br>
</blockquote><div><br></div><div>Hi Andrew, thank you for your answer.<br></div><div>I already know these concepts.<br></div><div>In my first mail I wrote<br>"My redundancy schema is -c 2 so, in any case, it wasn't possible to keep cluster consistency."<br>
<br></div><div>What I'm focusing on, is that after I've been able to _restore all cluster objects_ (so all vdi), their content was ruined.<br></div><div>More specifically, the content of the vdi that were used by running guests during the "crash".<br>
<br></div><div>My case couldn't be managed by sheepdog automatically, that's clear.<br></div><div>But it was possible to restore the cluster after "manual" intervention.<br><br></div>I use the analogy of raid 5 with 3 disks for simplicity (mdadm).<br>
</div><div class="gmail_quote">I tried to simulate a similar scenario:<br></div><div class="gmail_quote">- removed a disk.<br></div><div class="gmail_quote">  (nothing happens: no rebuild because now it behaves like a raid 0)<br>
</div><div class="gmail_quote">- removed the second disk<br>  Raid goes in failed status and the *filesystem in read-only*.<br></div><div class="gmail_quote">  Once plugged back the second disk, by a specific procedure, I'm able to re-assemble the failed raid.<br>
</div><div class="gmail_quote">  The filesystem is still consistent.<br><br></div><div class="gmail_quote">This is an extreme case that can't be managed automatically by mdadm obviously.<br></div><div class="gmail_quote">
It would be bad if, after re-assembling the array, the file system was corrupted.<br><br></div><div class="gmail_quote">Sheepdog should behave in analogous<span class=""></span> way.<br></div><div class="gmail_quote">It already does in case simultaneous nodes loss.<br>
It doesn't in case of simultaneous device loss (on different nodes).<br><br><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br><br></div></div></div>