1bdad60633
There are several reasons why this is undesirable:
1. It never happens during normal operation anyway
2. If it does happen it causes performance to be very, very poor
3. It isn't likely to solve the original problem (memory shortage
on remote DLM node) it was supposed to solve
4. It uses a bunch of arbitrary constants which are unlikely to be
correct for any particular situation and for which the tuning seems
to be a black art.
5. In an N node cluster, only 1/N of the dropped locked will actually
contribute to solving the problem on average.
So all in all we are better off without it. This also makes merging
the lock_dlm module into GFS2 a bit easier.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
27 lines
524 B
C
27 lines
524 B
C
/*
|
|
* Copyright (C) Sistina Software, Inc. 1997-2003 All rights reserved.
|
|
* Copyright (C) 2004-2006 Red Hat, Inc. All rights reserved.
|
|
*
|
|
* This copyrighted material is made available to anyone wishing to use,
|
|
* modify, copy, or redistribute it subject to the terms and conditions
|
|
* of the GNU General Public License version 2.
|
|
*/
|
|
|
|
#ifndef __GFS2_DOT_H__
|
|
#define __GFS2_DOT_H__
|
|
|
|
enum {
|
|
NO_CREATE = 0,
|
|
CREATE = 1,
|
|
};
|
|
|
|
enum {
|
|
NO_FORCE = 0,
|
|
FORCE = 1,
|
|
};
|
|
|
|
#define GFS2_FAST_NAME_SIZE 8
|
|
|
|
#endif /* __GFS2_DOT_H__ */
|
|
|