Chris Mason wrote:
> If you unmerge inside ext2_get_block...
I unmerge at a higher level - file_read, notify_change, delete_inode.
Inside my hacked ext2_get_block and ext2_commit_write I just handle
the tail data copy. I don't know for sure *why* I do it this way, it
just seems right and allows me to think more clearly about the
temporal issues involved. I think maybe the code is a little simpler
too because I don't have to keep any extra state information.
> ...you get passed bh_result. Just
> change bh_result->b_blocknr to your new block, set b_dev, and set it
> mapped, and copy the tail into bh_result. Then block_write_full_page or
> block_commit_write are the ones that dirty bh_result for you, no alias
> created.
I can use your suggestion to optimize the case where I am unmerging
the last inode in a merge ring. I would still have to worry about
making the original buffer go away - it's still hanging out in the
buffer cache hash table and I find that a little worrisome. Currently
I just free the block and let ext2_get_block reallocate it later,
letting those guys worry about the aliasing issues. This works, but
two trips into the block bitmaps could be eliminated.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
