On 8/10/00, 9:37:24 AM, Daniel Phillips <[EMAIL PROTECTED]> wrote
regarding Re: Tailmerging - more details:
> On Thu, 10 Aug 2000, Chris Mason wrote:
> > [ please let me know if you want anything in the cut text answered ;-) ]
> If you've got anything to say about map/unmap, something I haven't looked
at at
> all yet, I'm interested. Otherwise, It's back to the usual digging...
> I hope it's ok with you to cc back to the list... It's called 'trolling
for
> more feedback'. I'm also trying to be a little bit didactic about the
design
> process for the benefit of list lurkers. :-)
Not at all, for some reason the reply-all button only replied to you and
Al.
> > > The unmerge that happens in ext2_file_write looks like this:
> > > <start exclusive>
> > > ext2_get_block (inode, iblock, bh_result, 2) /* force tail to new
block */
> > > <clear the this inode's tail offset>
> > > <delete this inode from the merge list>
> > > <end exclusive>
> >
> > > The reason the unmerge is done here and not at a lower level in
ext2_get_block
> > > is, I don't want to have get_block go diving down into the innards of a
page
> > > it's not being asked to do I/O on. That could get pretty messy.
> >
> > Well, you'll have to do the same thing in writepage. Unmerging the tail
> > only requires reads from the buffer cache, so it is not too bad inside
> > get_block.
> Correct me if I'm wrong, but I think that if writepage ever needs to
unmerge at
> tail then it's an error. The tail should have already been unmerged by
the
> ext2_file_write, which must necessarily precede the writepage. Similarly
for
> file_mmap: I should unmerge the tail as soon as a file ever memapped, and
then
> a unmerge can't come from that source either.
Ah, now I see where you are going. If you mmap a file, and change the
contents, file_write is not involved in getting the changes to disk. So,
your code has to deal with a readpage on the tail, followed by a
writepage on the page filled in by readpage.
-chris
