[Gluster-devel] Read-only option for a replicated (replication for fail-over) Gluster volume

[Vijay Bellur]

On Tue, Mar 21, 2017 at 10:52 AM, Mackay, Michael <mackay at progeny.net>
wrote:

> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> All users will get data from the Gluster mount and use it, but from the
> beginning it would be read-only.
>
>
>
> A new deliver might have new data, or changed data, but that’s the only
> time it will change.
>
>
>
> I want to repeat as well that we’ve identified changes in the code
> baseline that allow this to work, if interested.
>
>
>
>
>

Would it be possible to send this patch on gerrit for master branch? You
can find the workflow for patch submission at [1].

Thanks,
Vijay

[1]
https://gluster.readthedocs.io/en/latest/Developer-guide/Development-Workflow/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170321/a57c6fcd/attachment-0001.html>