Cc: Andrew Morton <akpm@...>, Christian Borntraeger <borntraeger@...>, <linux-mm@...>, <linux-kernel@...>, Martin Schwidefsky <schwidefsky@...>, Theodore Ts'o <tytso@...>
On Tuesday 16 October 2007 13:14, Eric W. Biederman wrote:
Not really, it's just named funny. That's just a minor utility
function that more or less does what it says it should do.
The main problem is really that it's implementing a block device
who's data comes from its own buffercache :P. I think.
Double buffering. You no longer serve data out of your buffer
cache. All filesystem data was already double buffered anyway,
so we'd be just losing out on one layer of savings for metadata.
I think it's worthwhile, given that we'd have a "real" looking
block device and minus these bugs.
What magic restrictions on page allocations? Actually we have
fewer restrictions on page allocations because we can use
highmem! And the lowmem buffercache pages that we currently pin
(unsuccessfully, in the case of this bug) are now completely
reclaimable. And all your buffer heads are now reclaimable.
If you mean GFP_NOIO... I don't see any problem. Block device
drivers have to allocate memory with GFP_NOIO; this may have
been considered magic or deep badness back when the code was
written, but it's pretty simple and accepted now.
Yeah but that's not rd.c. You need to rewrite the buffer layer
to fix that (see fsblock ;)).
-
