On Tue, Jan 28, 2014 at 5:01 PM, Mikulas Patocka
<mikulas@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> The page cache doesn't handle different-size buffers for one page.
Correct, but that should not be relevant..
> HPFS
> has some 2kB structures (dnodes, bitmaps) and some 512-byte structures
> (fnodes, anodes). We can have a 4kB page that contains one 2kB dnode and
> four 512-byte anodes or fnodes. That is impossible to create with
> create_empty_buffers.
Damn. You're both right and wrong.
It's true that buffer heads within a page have to be the same size,
but that's not really relevant - you don't work with pages, so you
could have two totally independent 2kB buffer heads allocated to
within one page.
And that's actually how filesystems that virtually map pages do things
- they just fill the page with (equal-sized) buffer heads indexed on
the filesystem inode, and the buffer heads don't have to be related to
each other physically on the disk.
In fact, even the sizes don't even really *have* to be the same (in
theory the list of page buffers could point to five buffers: one 2k
and four 512-byte bhs), but all the helper functions to populate the
buffer head lists etc do assume that.
And way back when, buffer heads had their own hashed lookup, so even
with the bd_dev approach you could have two non-consecutive
independent 2kB bh's in the same page.
So you used to be wrong.
But the reason you're right is that we got rid of the buffer head
hashes, and now use the page-level hashing to look up the page that
the buffer heads are in, which does mean that now you can't really
alias different sizes on different pages any more, or have one page
that contains buffer heads that aren't related to each other
physically on the disk any more.
So yeah, very annoying, we're *so* close to being able to do this, but
because the buffer heads are really no longer "primary" data
structures and don't have any indexing of their own, we can't actually
do it.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
