Re: Backups with GFS and RAM sizing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> 
> 
> 




--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster

[Index of Archives]     [Corosync Cluster Engine]     [GFS]     [Linux Virtualization]     [Centos Virtualization]     [Centos]     [Linux RAID]     [Fedora Users]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Camping]

  Powered by Linux