<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I’m not sure if this went (email issues at the office), so re-sending.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Mackay, Michael <br><b>Sent:</b> Tuesday, March 21, 2017 5:01 PM<br><b>To:</b> gluster-devel@gluster.org<br><b>Subject:</b> RE: (nwl) Re: [Gluster-devel] Read-only option for a replicated (replication for fail-over) Gluster volume<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>At the risk of repeating myself, the POSIX file system underpinnings are not a concern – that part is understood and handled.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I’m also not asking for help to solve this problem, again, to be clear. SE Linux is not an option. To summarize the point of my post:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I’ve gotten what I want to work. I have a small list of code changes to make it work. I wish to find out if the Gluster community is interested in the changes.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Mike<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Dustin Black [<a href="mailto:dblack@redhat.com">mailto:dblack@redhat.com</a>] <br><b>Sent:</b> Tuesday, March 21, 2017 12:12 PM<br><b>To:</b> Mackay, Michael<br><b>Cc:</b> Saravanakumar Arumugam; Atin Mukherjee; <a href="mailto:gluster-devel@gluster.org">gluster-devel@gluster.org</a><br><b>Subject:</b> (nwl) Re: [Gluster-devel] Read-only option for a replicated (replication for fail-over) Gluster volume<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>I don't see how you could accomplish what you're describing purely through the gluster code. The bricks are mounted on the servers as standard local POSIX file systems, so there is always the chance that something could change the data outside of Gluster's control.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>This all seems overly-restrictive to me, given that your storage system should be locked-down from an administrative perspective as a best practice in the first place, limiting the risk of any brick-side corruption or in your case even writes/changes. But assuming that you have a compliance or other requirement that is forcing this configuration, why not simply mount the brick local file system as read only, and then also enable the existing Gluster read-only translator, providing two layers of protection against any writes? Of course this would also restrict any metadata actions on the Gluster side, which could be problematic for something like bitrot detection and could result in a lot of log noise, I'm guessing. And administratively someone could still get in and remount the bricks as r/w, so if you _really_ _really_ need it locked down you may also need selinux.<o:p></o:p></p></div><div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><div><div><div><div><div><div><div><div><div><div><div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Dustin Black, RHCA <o:p></o:p></p></div><div><p class=MsoNormal>Senior Architect, Software-Defined Storage<o:p></o:p></p></div><div><p class=MsoNormal>Red Hat, Inc.<br> <o:p></o:p></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Mar 21, 2017 at 10:52 AM, Mackay, Michael <<a href="mailto:mackay@progeny.net" target="_blank">mackay@progeny.net</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>All users will get data from the Gluster mount and use it, but from the beginning it would be read-only.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>A new deliver might have new data, or changed data, but that’s the only time it will change.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I want to repeat as well that we’ve identified changes in the code baseline that allow this to work, if interested.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I hope that provides the information you were looking for.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Mike</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Saravanakumar Arumugam [mailto:<a href="mailto:sarumuga@redhat.com" target="_blank">sarumuga@redhat.com</a>] <br><b>Sent:</b> Tuesday, March 21, 2017 10:18 AM<br><b>To:</b> Mackay, Michael; Atin Mukherjee</span><o:p></o:p></p><div><div><p class=MsoNormal><br><b>Cc:</b> <a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a><br><b>Subject:</b> Re: [Gluster-devel] Read-only option for a replicated (replication for fail-over) Gluster volume<o:p></o:p></p></div></div></div></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On 03/21/2017 07:33 PM, Mackay, Michael wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>“</span>read-only xlator is loaded at gluster server (brick) stack. so once the volume is in place, you'd need to enable read-only option using volume set and then you should be able to mount the volume which would provide you the read-only access.”<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>OK, so fair enough, but is the physical volume on which the brick resides allowed to be on a r/o filesystem? <o:p></o:p></p></blockquote><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><o:p> </o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Again, it’s not just whether Gluster considers the volume to be read-only to clients, but whether the gluster brick and its underlying medium can be read-only.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>No, it is only Gluster consider it as a read-only voume.<br><br>If you go and access the gluster brick directly, you will be able to write on it.<br>In general, you should avoid accessing the bricks directly.<br><br><br>Do you mean to say, like creating a gluster volume to be read-only even from the beginning ?<br>Can you tell about the use case ?<br><br>As I understand, user will write some data and wish all the data to be read-only. So, user set the volume to be read-only.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Atin Mukherjee [<a href="mailto:amukherj@redhat.com" target="_blank">mailto:amukherj@redhat.com</a>] <br><b>Sent:</b> Tuesday, March 21, 2017 9:42 AM<br><b>To:</b> Mackay, Michael<br><b>Cc:</b> Samikshan Bairagya; <a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a><br><b>Subject:</b> (nwl) Re: [Gluster-devel] Read-only option for a replicated (replication for fail-over) Gluster volume</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Tue, Mar 21, 2017 at 6:06 PM, Mackay, Michael <<a href="mailto:mackay@progeny.net" target="_blank">mackay@progeny.net</a>> wrote:<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Samikshan,<br><br>Thanks for your suggestion.<br><br>From what I understand, the read-only feature (which I had seen and researched) is a client option for mounting the filesystem. Unfortunately, we need the filesystem itself to be set up read-only, so that no one can modify it - in other words, we need to make sure that no client can mount it read/write. So, it has to be set up and started as r/o, and then the clients have no choice but to get a r/o copy.<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>read-only xlator is loaded at gluster server (brick) stack. so once the volume is in place, you'd need to enable read-only option using volume set and then you should be able to mount the volume which would provide you the read-only access. <br> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br>Thanks<br>Mike<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br>-----Original Message-----<br>From: Samikshan Bairagya [mailto:<a href="mailto:sbairagy@redhat.com" target="_blank">sbairagy@redhat.com</a>]<br>Sent: Monday, March 20, 2017 3:52 PM<br>To: Mackay, Michael<br>Cc: <a href="mailto:gluster-devel@gluster.org" target="_blank">gluster-devel@gluster.org</a><br>Subject: Re: [Gluster-devel] Read-only option for a replicated (replication for fail-over) Gluster volume<br><br><br><br>On 03/21/2017 12:38 AM, Mackay, Michael wrote:<br>> Gluster folks:<br>><br>> Our group has a need for a distributed filesystem, like Gluster, that can be mounted by clients as read-only. We wish to have the ability to seamless switch over to an alternate source of this read-only data if the default source fails.<br>> The reason for this ROFS is so that every client can get access to applications and data that we want to ensure stays the same (unmodifiable) for an entire system delivery life cycle. To date we've used read-only NFS mounts reasonably well, but its failover performance is not at all great.<br>><br>> We also don't want a "WORM" sort of arrangement - we want to prevent any and all writes to the volume once it's up and shared.<br>><br>> So, under the "how hard could it be" mantra, we took version 3.7.15 and poked around a bit until we got it to do just what we want. It was a minor mod to 'xlators/features/index/src/index.c' and 'xlators/storage/posix/src/posix-helpers.c', along with a "force" option when doing the volume start command.<br>><br>> We would happily share the specific changes, and they seem to fit in the 3.10.0 code base too; the question for the group is, would such a capability be of interest to the Gluster baseline? Possibly a precursor question (since I don't have much experience in gluster-devel at all, so please forgive my approach if it's wrong) is, to whom should I pose this question, if it's not to this group?<br>><br>> Thanks for your time and I'd be happy to provide any further information.<br>><br><br>Hi Mike,<br><br>Have you checked the 'features.read-only' volume option. Apparently you can set it to on/off depending on whether you want your volume to be read-only or not. By default it is set to 'off'. The following would make your volume read-only for all clients accessing it:<br><br># gluster volume set <VOLNAME> features.read-only on<br><br>Hope that helped.<br><br>~ Samikshan<br>_______________________________________________<br>Gluster-devel mailing list<br><a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br><a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://lists.gluster.org/mailman/listinfo/gluster-devel</a><o:p></o:p></p></div></div></blockquote></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br clear=all><br>-- <o:p></o:p></p><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>~ Atin (atinm)<o:p></o:p></p></div></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><o:p> </o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Gluster-devel mailing list<o:p></o:p></pre><pre><a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><o:p></o:p></pre><pre><a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://lists.gluster.org/mailman/listinfo/gluster-devel</a><o:p></o:p></pre><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></div></div><p class=MsoNormal><br>_______________________________________________<br>Gluster-devel mailing list<br><a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br><a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" target="_blank">http://lists.gluster.org/mailman/listinfo/gluster-devel</a><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>