Hi,
Please queue the following two patches for the next merge window
for dlm. The first one adds a new sysfs variable so that the
lockspace can be obtained without resorting to parsing the
initial line of the sysfs message.
The second one removes some obsolete code relating to one of the
sysfs
Although it is possible to get this information from the path,
its much easier to provide the lockspace as a seperate env
variable.
Signed-off-by: Steven Whitehouse swhit...@redhat.com
---
fs/dlm/lockspace.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git
We don't need to look up the lockspace in this particular
case since we already have a pointer to it (which was being
dereferenced in order to do the lookup in the first place).
Signed-off-by: Steven Whitehouse swhit...@redhat.com
---
fs/dlm/lockspace.c |6 +-
1 files changed, 1
While investigating Red Hat bug #537010 I started looking at the dlm's astd
thread. The way in which the cast and bast requests are queued looked
as if it might cause reordering since the bast requests are always
delivered after any pending cast requests which is not always the
correct ordering.
One of the reasons that ASTs are delivered in a separate thread was to
allow ASTs do do other locking operations without causing a deadlock.
eg. it would allow locks to be dropped or converted inside a blocking
AST callback routine.
So maybe either the new code already allows for this or it's
Hi,
On Wed, 2010-02-17 at 13:43 +, Christine Caulfield wrote:
One of the reasons that ASTs are delivered in a separate thread was to
allow ASTs do do other locking operations without causing a deadlock.
eg. it would allow locks to be dropped or converted inside a blocking
AST callback
On Wed, Feb 17, 2010 at 09:41:35AM +, Steven Whitehouse wrote:
We don't need to look up the lockspace in this particular
case since we already have a pointer to it (which was being
dereferenced in order to do the lookup in the first place).
It'll take more to convince me that that
On Wed, Feb 17, 2010 at 01:23:39PM +, Steven Whitehouse wrote:
While investigating Red Hat bug #537010 I started looking at the dlm's astd
thread. The way in which the cast and bast requests are queued looked
as if it might cause reordering since the bast requests are always
delivered
