>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 > > > -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
