[Linux-cluster] Backups with GFS and RAM sizing

[Danny Wall]

>I was suggesting just having the backup node mount the fs during the
> backup, unmounting from all others (assuming they could do without it).

Unfortunately, this is a cardiology imaging system, so it can not be
taken down for backups.

>Just to be clear, mount -o remount isn't sufficient to clear out the
> unwanted cache, an unmount is required followed by a mount.

Thanks for clarifying. That would have thrown me.

Danny

On Fri, 2007-07-20 at 12:44 -0500, David Teigland wrote:
> On Fri, Jul 20, 2007 at 01:32:40PM -0400, Danny Wall wrote:
> > Thanks for the information. I am a little hesitant about mounting with
> > the no_lock option during backups, since the filesystem will be mounted
> > on multiple nodes. Currently, only one node writes to the filesystem at
> > a time, then the backups run on the other node, but I imagine there
> > could still be locking problems between the two.
> 
> I was suggesting just having the backup node mount the fs during the
> backup, unmounting from all others (assuming they could do without it).
> 
> > The /proc/cluster/lock_dlm/drop_count was 50000. After echo the 0, it
> > stayed at 0 for a while, and has not gone up yet. I'm not sure what it
> > should be, but it did not make a difference on its own. I guess I will
> > have to research these.
> 
> It's a config setting so it won't change.  A non-zero value limits the
> lock caching gfs can do which limits performance.  In the release you're
> using I believe you need to set it before mounting for it to have any
> impact on the fs.
> 
> > I will add a remount at the end of backups to see if that helps any. We
> > might be updating later this year, so hopefully this would address #3 at
> > that time.
> 
> Just to be clear, mount -o remount isn't sufficient to clear out the
> unwanted cache, an unmount is required followed by a mount.
> 
> Dave
> 
> 
>