[Linux-cluster] Backups with GFS and RAM sizing

[Danny Wall]

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.

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.

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.

Thanks

On Fri, 2007-07-20 at 11:16 -0500, David Teigland wrote:
> On Wed, Jul 11, 2007 at 11:15:54AM -0400, Danny Wall wrote:
> > My backups are taking a very long time, and I am looking for ways to
> > optimize the process, so suggestions are welcome.
> 
> I suspect that a large part of this is just the inherent slowness of gfs.
> Here are some ideas to try,
> 1. echo "0" > /proc/cluster/lock_dlm/drop_count
> 2. mount each fs with nolock during the backup (mount -o lockproto=lock_nolock)
> 3. unmount/remount each fs after the backup is done with it to get rid
>    of the excessive unwanted caching effects from scanning the whole fs
> 4. use the glock_purge feature that's in 4.5 (which approximates 3 without
>    the unmount)
> 
> Dave
> 
> 
>