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...
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
