> -----Original Message----- > From: linux-cluster-bounces@xxxxxxxxxx [mailto:linux-cluster-bounces@xxxxxxxxxx] > On Behalf Of Allen Belletti > Sent: Friday, October 02, 2009 12:27 PM > To: linux clustering > Subject: 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 -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
