<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 21, 2017 at 10:52 AM, Mackay, Michael <span dir="ltr">&lt;<a href="mailto:mackay@progeny.net" target="_blank">mackay@progeny.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="white" lang="EN-US"><div class="gmail-m_-3145294905406755168WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">Thanks for the help and advice so far.  It’s difficult at times to describe what the use case is, so I’ll try here.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">We need to make sure that no one can write to the physical volume in any way.  We want to be able to be sure that it can’t be corrupted. We know from working with Gluster that we shouldn’t access the brick directly, and that’s part of the point.  We want to make it so it’s impossible to write to the volume or the brick under any circumstances.  At the same time, we like Gluster’s recovery capability, so if one of two copies of the data becomes unavailable (due to failure of the host server or maintenance) the other copy will still be up and available.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">Essentially, the filesystem under the brick is a physically read-only disk that is set up at integration time and delivered read-only.  We won’t want to change it after delivery, and (in this case for security) we want it to be immutable so we know we can rely on that data to be the same always, no matter what.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">All users will get data from the Gluster mount and use it, but from the beginning it would be read-only.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">A new deliver might have new data, or changed data, but that’s the only time it will change.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">I want to repeat as well that we’ve identified changes in the code baseline that allow this to work, if interested.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><br></p></div></div></blockquote><div><br></div><div><br></div><div>Would it be possible to send this patch on gerrit for master branch? You can find the workflow for patch submission at [1].</div><div><br></div><div>Thanks,</div><div>Vijay</div><div><br></div><div>[1] <a href="https://gluster.readthedocs.io/en/latest/Developer-guide/Development-Workflow/">https://gluster.readthedocs.io/en/latest/Developer-guide/Development-Workflow/</a>  </div></div></div></div>