On Tue, 12 Sep 2000, Daniel Phillips wrote:
> Alexander Viro wrote:
> >
> > On Tue, 12 Sep 2000, Daniel Phillips wrote:
> >
> > Wait a minute. block_*_page is pure library stuff. VFS doesn't use it - it
> > just happens to be common for many filesystems, thus it had been placed
> > into fs/buffer.c.
> >
> > There is absolutely no need to make it work in your case.
>
> 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.
> 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.
> these.) Yes, I know I can write a whole new set of VFS functions but
> I'd rather just fix this one and get on with life. Did you think I
> was trying to do the tailmerge generically for VFS? Ah, no, I have my
> sights set lower, it's only for Ext2 and if it happens to be
> applicable to other block filesystems that's nice.
So change ext2_prepare_write() and friends...
> > 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
