On Fri, 8 Sep 2000, Stephen C. Tweedie wrote:
> Right, and I've already got patches which drop the superblock lock for
> nearly all of balloc.c and ialloc.c. It's not hard in principle, and
> I'll redo what I had for 2.4-current.
Want directories-in-pagecache in a mix? ;-)
BTW, BKL is not actually needed that much on block pointers - see
/* Writer: * and /* Reader: */ comments.
> > For bitmaps we will
> > need a spinlock per cg for search/modifications/counters updates. Add
> > one more for descriptor cache and that's it. I'll try to dig out
> > pre-patches along these lines - I should have them somewhere.
>
> Right. My last stuff was, I think, before we dropped the BKL
> throughout this code so I'll have to double-check whether any such
> races remain.
? <looks> wait a second, BKL is still there...
> > The worst problem is with the quota alocation/deallocation. Currently it
> > blocks and it actually gives bad races (i_blocks getting out of sync with
> > the quota and dquot_transfer() doing the wrong things).
>
> What races? I don't think that quota updates will need to be atomic
> as long as they eventuall complete. dquot_transfer() is indeed a
> potential problem, but we don't need to serialise normal quota ops to
> fix that --- we just need to make dquot_transfer lock out other
> operations while it plays its games.
That's not all, unfortunately. incrementing/decrementing the quota has
exclusion with dquot_{read,write}. Blocking one. So you are getting
considerable intervals when ->i_blocks and quota (in-core) are
out-of-sync. Which is a bad thing. If you need more details - let's take
it to email for a while, OK? I said that it was exploitable and I mean
it ;-<
> > issues (exploitable quota leaks are _not_ fun). Modulo that problem we can
> > actually get rid of ->s_lock inside the fs/ext2/* completely...
>
> Agreed, but it's probably even easier to get rid of it _mostly_ than
> to totally remove it. In particular, the s_lock protects the bitmap
> cache, and that is easy to replace with a cache function which simply
> bumps the refcount on the buffer_head --- there's no need to lock it
> there. Bitmap updates _can_ be done with atomic bitops, but we
> probably don't want to --- if we have two processes allocating from
> the same block group, we'll get better disk layout if they get
> serialised at least during the bitmap update. The subsequent quota
> update doesn't need serialising, and neither does the group status
> information if we use atomic types there.
It's not subsequent and that's the problem. Check the preallocation loop.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
