>On Thu, 22 Apr 1999, Andrea Arcangeli wrote:
>
>> I think there's another subtle bug in set_blocksize() and
>> invalidate_buffers(). The problem is that buffers can be moved across
>> lists and can be moved across the same list while we are sleeping on a
>> locked buffer. This patch address the problem. I never run it on a clean
>> 2.2.6, but I am doing these things in my sligthly rewritten buffer.c. It
>> address also the problem described by Alexander in a safer way because
>> performances after set_blocksize run, are really not an issue, so we can
> ^^^^^^^^^^^^^^^^^^^^^^^
> Excuse me, why? Lots of
>filesystems do it in read_super(). AFAICS you've just added an overhead to
>mount().
I agree that it's desiderable to move buffers to the freelist but you
should at least also check the reference count while instead my approch
make no assumption on the correctness of the set_blocksize caller code.
And I really don't think it will make big difference, this is why I think
that the lazy approch will be just fine.
>[snip]
>> @@ -653,10 +629,13 @@
>> * around on the free list, and we can get in a loop if we are not careful.
>> */
>> for(nlist = 0; nlist < NR_LIST; nlist++) {
>> + refiled:
>> bh = lru_list[nlist];
>> for (i = nr_buffers_type[nlist]*2 ; --i > 0 ; bh = bhnext) {
>> if(!bh)
>> break;
>> + if (bh->b_list != nlist)
>> + goto refiled;
>
> Ahem... Busy-waiting is fun, ain't it? What did you really mean
>in the chunk above?
Starting from the second run of the loop bh is == bhnext. But bhnext is
been moved from the dirty list to the clean list while we was sleeping in
wait_on_buffer(). So without my patch we could continue browsing the clean
list instead of continue to browse the dirty list.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/