Nick Piggin <nickpiggin@yahoo.com.au> writes:

quoted text
> On Tuesday 16 October 2007 18:08, Nick Piggin wrote:
>> On Tuesday 16 October 2007 14:57, Eric W. Biederman wrote:
>
>> > > What magic restrictions on page allocations? Actually we have
>> > > fewer restrictions on page allocations because we can use
>> > > highmem!
>> >
>> > With the proposed rewrite yes.
>
> Here's a quick first hack...
>
> Comments?

I have beaten my version of this into working shape, and things
seem ok.

However I'm beginning to think that the real solution is to remove
the dependence on buffer heads for caching the disk mapping for
data pages, and move the metadata buffer heads off of the block
device page cache pages.  Although I am just a touch concerned
there may be an issue with using filesystem tools while the
filesystem is mounted if I move the metadata buffer heads.

If we were to move the metadata buffer heads (assuming I haven't
missed some weird dependency) then I think there a bunch of
weird corner cases that would be simplified.

I guess that is where I look next.

Oh for what it is worth I took a quick look at fsblock and I don't think
struct fsblock makes much sense as a block mapping translation layer for
the data path where the current page caches works well.  For less
then the cost of 1 fsblock I can cache all of the translations for a
1K filesystem on a 4K page.

I haven't looked to see if fsblock makes sense to use as a buffer head
replacement yet.

Anyway off to bed with me.

Eric
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/