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
