Hi, On Tue, 2012-04-10 at 10:08 -0400, David Teigland wrote: > On Tue, Apr 10, 2012 at 10:12:28AM +0100, Steven Whitehouse wrote: > > Hi, > > > > On Thu, 2012-04-05 at 12:11 -0400, Bob Peterson wrote: > > > Hi, > > > > > > Here's another patch (explanation below). This patch replies upon > > > a DLM patch that hasn't fully gone upstream yet, so perhaps it > > > shouldn't be added to the nmw tree until it is. This greatly > > > improves the performance of gfs2_grow in a clustered gfs2 file system. > > > > > > Regards, > > > > > I'm still not very keen on dragging in this bit of dlm. If it is really > > needed, then we should use the copy in the dlm itself and not add our > > own copy of it. > > The table is equivalent to: > (rq_mode > gr_mode) || (gr_mode == PR && rq_mode == CW) > The GLF_BLOCKING flags is almost identical to that, except that it is also cleared on try locks. I don't think that makes any difference in this case. Since we already distinguish between getting a new DLM lock and conversions, it should just be a case of setting the QUECVT flag in the conversion branch if the GLF_BLOCKING flag is set if I've understood whats going on correctly here.
> > When you say that this relies upon this dlm patch, what does that mean? > > What are the consequences of having this patch but not the dlm one? I'm > > wondering whether I should hold off on this at least until the dlm one > > has been finalised and applied. > > Yeah, using QUECVT everywhere will make things worse until it's fixed. > Ok, I'll hold off merging this (or whatever we land up with, finally) until the DLM patch has reached a similar stage in that case, Steve.
