Well to put it another way, mark_page_uptodate() is the only
place where we really need to know about the upper layers.
Given that you can kill ramdisks by coding it as:
static void make_page_uptodate(struct page *page)
{
clear_highpage(page);
flush_dcache_page(page);
SetPageUptodate(page);
}
Something is seriously non-intuitive about that function if
you understand the usual rules for how to use the page cache.
The problem is that we support a case in the buffer cache
where pages are partially uptodate and only the buffer_heads
remember which parts are valid. Assuming we are using them
correctly.
Having to walk through all of the buffer heads in make_page_uptodate
seems to me to be a nasty layering violation in rd.c
Yep we are in agreement there.
For testing purposes I think I can agree with that.
With the proposed rewrite yes.
Hmm. Good point. So in net it should save memory even if
it consumes a little more in the worst case.
Well I always figured it was a bit rude allocating large amounts
of memory GFP_NOIO but whatever.
I'm not certain which way we should go. Take fsblock and run it
in parallel until everything is converted or use fsblock as a
prototype and once we have figured out which way we should go
convert struct buffer_head into struct fsblock one patch at a time.
I'm inclined to think we should evolve the buffer_head.
Eric
-
