On 8 Sep 2000, Juan J. Quintela wrote:
> al> replacing with a spinlock, true, but then we would be better off making it
> al> per-cylinder group...
>
> 1- once explained what I intended to tell, what do you think?
> 2- could you elaborate in the spinlock by cylinder group? I could try
> to change that.
Umm... OK, look at it that way: what are we protecting with ->s_lock?
Aside of serializing ->read_super() and friends, that is. Three things:
1) cache of cylinder group descriptors
2) block bitmaps and counters
3) inode bitmaps and counters
None of them actually needs a blocking lock at all. 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.
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). I think that I
know how to deal with that, but it I'll probably have to look at it for a
while to tell for sure... That needs to be fixed regardless of contention
issues (exploitable quota leaks are _not_ fun). Modulo that problem we can
actually get rid of ->s_lock inside the fs/ext2/* completely...
I'm less than sure that complete threading is a 2.4 thing, though.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
