On 06.10.2011 22:54, Andrey Kuzmin wrote: > > > On Friday, October 7, 2011, Andi Kleen <andi@xxxxxxxxxxxxxx > <mailto:andi@xxxxxxxxxxxxxx>> wrote: >> On Fri, Oct 07, 2011 at 12:44:30AM +0400, Andrey Kuzmin wrote: >>> Perhaps you could just elaborate on "needs this feature"? In general, write >>> lock gives one exclusive access, so the need for additional read >>> (non-exclusive) lock does not appear easily understandable. >> >> Usually it's because the low level code can be called both with and >> without locking and it doesn't know. >> >> But that usually can be avoided with some restructuring. > Exactly. One premise was to change the existing paths as little as possible to make it easier for Chris to judge the impact when qgroups are turned off. For this I hook into the generic "add a backref" path, which is called from diverse places all around the code. Some of these places already hold a lock on the fs tree I'm going to read, others don't, but in any case it is ok to just go ahead and read it. I think by restructuring you mean serializing both operations and only calling into my code after the previous operation is done. But that would on one hand mean queuing up all that needs to be done afterwards, and on the other hand at least keeping a read lock on all these extents, as no changes are allowed in between. This restructuring would be a major operation, but maybe I'm just not seeing the obvious way to go. Maybe Chris has a good idea... All my code is now doing is when it encounters a write lock, check if the upper layers are holding it and allowing read access if that's the case. Only one additional reader is allowed. This is not full recursive locking, but at least part of it. -Arne >> >> -Andi >> > > -- > Sent from Gmail Mobile -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
