On Tue, Mar 21, 2017 at 10:52 AM, Mackay, Michael <[email protected]> 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/
_______________________________________________ Gluster-devel mailing list [email protected] http://lists.gluster.org/mailman/listinfo/gluster-devel
