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

[Atin Mukherjee]

On Tue, Mar 21, 2017 at 6:06 PM, Mackay, Michael <mackay at progeny.net> wrote:

> Samikshan,
>
> Thanks for your suggestion.
>
> 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.
>

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.


>
> Thanks
> Mike
>
> -----Original Message-----
> From: Samikshan Bairagya [mailto:sbairagy at redhat.com]
> Sent: Monday, March 20, 2017 3:52 PM
> To: Mackay, Michael
> Cc: gluster-devel at gluster.org
> Subject: Re: [Gluster-devel] Read-only option for a replicated
> (replication for fail-over) Gluster volume
>
>
>
> On 03/21/2017 12:38 AM, Mackay, Michael wrote:
> > Gluster folks:
> >
> > 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.
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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?
> >
> > Thanks for your time and I'd be happy to provide any further information.
> >
>
> Hi Mike,
>
> 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:
>
> # gluster volume set <VOLNAME> features.read-only on
>
> Hope that helped.
>
> ~ Samikshan
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 

~ Atin (atinm)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170321/6d9f4e65/attachment.html>