--On 09/10/00 00:38:31 +0200 Daniel Phillips
<[EMAIL PROTECTED]> wrote:
> Here's what's on my mind: block_write_full_page does not use the
> filesystem's prepare_write and commit_write methods, instead it calls
> its own internal functions. Presumeably this is done for efficiency,
> but it limits flexibility.
>
> Reading the code, I can't see any reason right off why the filesystem
> override methods couldn't be used. The biggest efficiency hit would
> be in __block_write_full_page where you couldn't combine the
> prepare_page and commit_page loops any more. Since we are calling
> through to the filesystem's get_block method here anyway I think the
> extra overhead would be trivial, and a lot of duplicated code could be
> got rid of.
>
> This caused a problem with tailmerging. It turned out that
> generic_file_read and generic_file_write could be extended reasonably
> elegantly to handle merged file tails in place. Not so with
> generic_file_mmap: because of the end run the buffer code does around
> the prepare_write and commit_write methods, I just can't do it with
> tails in place, at least not without inhaling large amounts of buffer
> system code. This is probably a 'big deal' kind of situation, because
> I can just unmerge any file that gets mmap'ed and probably nobody will
> notice. But still...
>
looking at block_write_full_page, __block_write_full_page won't get called
for the last page of the file, so it should never have to deal with tails.
But even if it did, calling __block_write_full_page should trigger your
existing get_block code to convert the tail into a full block. This could
be the same code you are using for writing/appending to a file.
It really should not be that ugly to write directly into the merged tail
though.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
