On Fri, Oct 29, 2004 at 02:40:33PM -0700, Daniel McNeil wrote: > Can you explain what gfs does with the callback? Does it drop the locks > for all gfs inodes or just the ones that are not actively being used? > Does gfs still cache the inode without holding the dlm lock? It releases all its unused (cached) locks which includes releasing the corresponding cached data. > How much memory does a dlm lock take? 10,000 seems very small > for machines today. > > Would it make sense to limit the number of gfs inodes which, > in turn, would limit the number of dlm_locks? > > It seems to me the number of inodes and number of dlm locks > should scale together. GFS is already quite good at limiting the caching it does without this drop-locks mechanism. The drop-locks callback is really an emergency button that shouldn't be used regularly as it disrupts all the intelligent things gfs is doing. Since lock_dlm really has no idea when the dlm is setting up for a potential recovery mem shortage, it can be argued that by default we should ignore the callback -- that's what we did until recently. So, this callback, designed many years ago for very different (centralized) lock managers, doesn't work too well for the dlm. As I mentioned, there are other better ways we can solve dlm recovery limitations. Until then, we'll hope to find some sensible defaults and guidelines on when/how to configure /proc/cluster/lock_dlm/drop_count. -- Dave Teigland <teigland@xxxxxxxxxx>
