--On 09/11/00 19:16:47 +0200 Daniel Phillips
<[EMAIL PROTECTED]> wrote:
>
> Simply stated, the new cache design divides filesystem blocks into two
> classes: those that can be memory-mapped and those that can't. There
> is no defined way to move a given block from one class to the other.
>
> This is the sequence of events for a tail unmerge:
>
> - Fix up various inode fields
> - bread the tail block
> - Allocate new block from ext2, map it into a buffer with getblk
> - Copy the tail fragment to the buffer of the newly allocated block
> - Mark the buffer dirty and go away
>
It isn't as bad as you think ;-) They key is to only unmerge into the page
cache. If you can't unmerge only into the page cache, you need to do a
getblk in your get_block call, and deal with the aliases.
If you unmerge inside ext2_get_block, 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.
You still run into races between truncate and writepage, I'm fixing this in
the next reiserfs release by keeping the last page locked for the duration
of the truncate.
You also have to be very careful during the unmerge not to allow up to date
information in the page cache to be overwritten by old data from the disk.
block_write_full_page will trigger a get_block on an up to date page, while
generic_file_write could trigger it for old or new data.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
