Messages in this thread | | | Date | Tue, 26 Jun 2007 12:34:26 +1000 | From | Nick Piggin <> | Subject | Re: [patch 1/3] add the fsblock layer |
| |
Chris Mason wrote: > On Mon, Jun 25, 2007 at 05:41:58PM +1000, Nick Piggin wrote: > >>Neil Brown wrote:
>>>Why do you think you need PG_blocks? >> >>Block device pagecache (buffer cache) has to be able to accept >>attachment of either buffers or blocks for filesystem metadata, >>and call into either buffer.c or fsblock.c based on that. >> >>If the page flag is really important, we can do some awful hack >>like assuming the first long of the private data is flags, and >>those flags will tell us whether the structure is a buffer_head >>or fsblock ;) But for now it is just easier to use a page flag. > > > The block device pagecache isn't special, and certainly isn't that much > code. I would suggest keeping it buffer head specific and making a > second variant that does only fsblocks. This is mostly to keep the > semantics of PagePrivate sane, lets not fuzz the line.
That would require a new inode and address_space for the fsblock type blockdev pagecache, wouldn't it? I just can't think of a better non-intrusive way of allowing a buffer_head filesystem and an fsblock filesystem to live on the same blkdev together.
-- SUSE Labs, Novell Inc. - 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/
| |