"Eric W. Biederman" wrote:
> Hans Reiser <[EMAIL PROTECTED]> writes:
>
> > I feel we should encourage Linus to allow the following:
> >
> > * unions in struct buffer_head and struct page containing filesystem specific
> > fields comparable to the union in struct inode.
>
> No.
>
> In struct buffer_head I don't have problems.
>
> In struct page (you don't want to pay the overhead for every page of memory)...
> There is the buffer_head *bh pointer that could be made more generic.
Ok, I agree bytes are precious, and this seems like the right answer, either get it
from the buffer_head, or if there is no buffer head, then put it elsewhere using
that pointer. That leaves the following questions though: how does one know whether
it points to a buffer head or the something else, and what happens when it goes from
having a buffer head to not having one---does one have to write code for dealing
with that---I hate complexity. I must think about it.
>
>
> >
> > * a filesystem operation which flushes to disk a buffer or page, and leaves it
> > to the filesystem whether to flush a whole commit along with it, or a whole
> > bunch of semantically adjacent buffers, or to repack the buffers before writing
> > them, or to write a whole bunch of semantically nearby buffers, or to fill the
> > rest of the RAID stripe, or assign a block number to the page, or mark the page
> > copy_on_write, or whatever else it wants.
>
> Or allocate bounce buffers, for high memory pages. . .
Good one....
>
>
> Though I don't think copy_on_write and (whatever else it wants)
> are necessarily hot ideas. There need to be some constraints.
Why don't you like copy_on_write? I thought it was a proven OS design meme?
It could make managing multiple commits with overlapping buffers cleaner.
Hans
--
Get Linux (http://www.kernel.org) plus ReiserFS
(http://devlinux.org/namesys). If you sell an OS or
internet appliance, buy a port of ReiserFS! If you
need customizations and industrial grade support, we sell them.
