Alexander Viro wrote:
>
> On Tue, 12 Sep 2000, Daniel Phillips wrote:
> >
> > There is a very heavy investment in generic_read/write/mmap - I don't
> > want to throw that away. This is a mod to Ext2, and Ext2 uses these
>
> Oh, but these functions don't need to be modified. Change
> address_space_operations and they will be happy.
I've been doing that all along and it works fine... but only for
generic_file_write, not for generic_file_mmap.
> > library functions heavily. (As you know, because I think you wrote
>
> Didn't. They were around since long and the last non-trivial
> rewrite was done by Ingo. I've changed them to use address_space_operations,
> but impact on the mm/filemap.c was not that serious.
OK, it is the use of the address_space operations that allows Ext2 to
use generic_write wheree before it could only use generic_read and
generic_mmap (bmap functionality). This address_space work I
attributed to you and I would not call it trivial.
> > > Make your expanding truncate() call ->prepare_write() and you are done -
> > > just put all unmerging into your instance of ->prepare_write(). That's it.
> > > Nothing forces you to use block_prepare_write() there.
> >
> > What about truncate? Truncate has to unmerge the tail without leaving
> > an alias around. As far as I can see the only clean way to do that is
> > to map the tail page of the file and copy in the tail data. The
>
> Yep. So make your truncate() (expanding one - there's hardly a
> reason to do it when you shrink stuff) do grab_cache_page() followed by
> ->prepare_write(NULL,page,new_offset,new_offset) and you are done - it's
> not a special case anymore.
Prepare_write does a lot of stuff associated with actual I/O. I don't
need to start a write here, or a read - just get the data onto the
page with the buffers in a consistent state and let ext2_get_block
create the new, unmerged tail block later. I just rewrote this part
to use grab_cache_page, but I can't test it yet because I also need
create_empty_buffers which isn't exported. I've run out of steam for
today; I'll do it tomorrow and I expect to report successful and
efficient elimination of buffer aliases.
Incidently, I have to unmerge on truncate whether I'm expanding or
shrinking - the only case I don't have to unmerge is when the truncate
falls within the tail fragment.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
