[Linux-cluster] GFS2 read only node for backups

[Jeff Sturm]

> -----Original Message-----
> From: linux-cluster-bounces at redhat.com
[mailto:linux-cluster-bounces at redhat.com]
> On Behalf Of Allen Belletti
> Sent: Friday, October 02, 2009 12:27 PM
> To: linux clustering
> Subject: [Linux-cluster] GFS2 read only node for backups
>  
> 1.  What does spectator mode do exactly?  Is it just the same as
> specifying "ro" or are there other optimizations?

A GFS spectator mount cannot successfully mount a read-only block
device.  It requires read-write access to the device.  So it behaves a
little differently than an ordinary "ro" mount.

Plus, with an ordinary "ro" mount the files will all be unchanging,
whereas a spectator mount allows files and directories to be modified
(by another node) while it is mounted, even though the node with the
spectator mount cannot write to the filesystem.

Thus the spectator mount is not strictly a read-only or read-write
mount, but sort of a hybrid of the two.

We don't use GFS2, but I am guessing it is similar in this regard.

> 2.  Would it be possible to have a mount mode that's strictly
read-only,
> no locking, and incorporates tolerance for errors?

I don't know for certain, but I don't think the lock_nolock approach
will work, unless you can snapshot the volume.

We were faced with the same questions you have.  Here's what we did:

a) run "gfs_tool freeze" on the mounted GFS filesystem to suspend
activity.
b) take a volume snapshot on our SAN block storage device.
c) run "gfs_tool unfreeze" to resume filesystem activity.
d) repeat a-c for each mounted GFS filesystem.

Once you have a snapshot, it of course can be mounted exclusively on a
single node with lockproto=lock_nolock as the filesystem contents will
be unchanging, and you can take as much time as necessary to rsync its
contents to another storage device without  impact to the active GFS
filesystem (assuming sufficient disk/network bandwidth are available for
the transfer).


-Jeff