> Well, I really wonder if buffers are the right transport medium for
> variable, large blocks, aka extents. Personally, I think buffers will
> have disappeared or mutated unrecognizably by the time we get around to
> adding extents to ext2 or its descendents. Note that XFS already
> implements extents on Linux, by mapping them onto the pagecache I
> believe.
Yes, JFS as well, but this is somewhat unrelated to using buffers as io
handles.
>
>> If we relax the rules to allow multiple buffer heads for
>> the same physical spot on disk, things get easier, and the FS is
>> responsible for not doing something stupid with it.
>>
>> The data is still consistent either way, there are just multiple io
>> handles.
>
> Were you thinking of one mapping for all buffers on a given partition?
one mapping for all buffers accessed through getblk, get_hash_table, bread,
and the block device.
> If so, how did you plan to handle different buffer sizes? Were you
> planning to keep the existing buffer hash chain or use the page cache
> hash chain, as I did for ext2_getblk?
It would be through page->buffers. Of course, this part is entirely
uncoded, but the nice thing about an address space on top of the physical
device is that bh->b_blocknr and bh->b_size directly compute to the offset
in the device. This means the order of the buffers on page->buffers does
not have to be related to the location of the data they point to.
So, along the lines of what Andrea suggested, buffer heads can be allocated
as needed, regardless of the blocksizes already in use in the page. The
current blkdev page cache code would need to be updated to use this idea,
but it should work.
-chris
-
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/