<p dir="ltr"></p>
<p dir="ltr">-Atin<br>
Sent from one plus one<br>
On Jul 5, 2015 10:16 AM, "Avra Sengupta" <<a href="mailto:asengupt@redhat.com">asengupt@redhat.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> Today with with enabling volume set option cluster.enable-shared-storage, we create a shared storage volume called gluster_shared_storage for the user, and mount it on all the nodes in the cluster. Currently this volume is used for features like nfs-ganesha, snapshot scheduler and geo-replication to save some internal data required by these features. The brick path we use to create this shared storage is /var/run/gluster/ss_brick.<br>
><br>
> The problem with using this brick path is /var/run/gluster is a tmpfs and all the brick/shared storage data will be wiped off when the node restarts. Hence I propose using /var/lib/glusterd/ss_brick as the brick path for shared storage volume as this brick and the shared storage volume is internally created by us (albeit on user's request), and contains only internal state data and no user data.<br>
><br>
> We are also aware that admins sometime take backup of /var/lib/glusterd to save the current state of gluster. Again this shouldn't be an issue as the data contained in these bricks is only internal state data and is very minimal.<br>
If its minimal I don't see any issue here.<br>
><br>
> Please let me know if there are any issues or concerns with using /var/lib/glusterd/ss_brick as the brick path for the shared storage, and also suggest an alternate brick path.<br>
><br>
> Regards,<br>
> Avra<br>
> _______________________________________________<br>
> Gluster-devel mailing list<br>
> <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
> <a href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
</p>