Dave Kleikamp wrote:
>
> ...
> > i_sem was already taken way up in do_truncate(), so that
> > approach may not be promising.
>
> I think that's okay. Now we take the IWRITE_LOCK near the level where
> we're called from the VFS, so we should be able to only grab i_sem in
> the paths that it's not already taken. I think we will know when to
> take it and when not to. If we take that approach, I'll have to make
> sure we protect those things that aren't protected by i_sem (in
> particular, anything that jfs_get_block may change).
Ah, I see. So those dirty pages would come back after
recovery as file holes.
We could change the generic_writeback_mapping() definition so
the fs must pass in the address of its writepage function. So
in the commit path you could call generic_writeback_mapping()
directly and pass in the address of:
int jfs_writepage_only_if_it_has_buffers(struct page *page)
{
if (page_has_buffers(page))
return jfs_writepage(page);
set_page_dirty(page); /* Not SetPageDirty()! */
unlock_page(page);
return 0;
}
I think I need to change generic_writeback_mapping() in that
manner anyway, to support multipage-BIO assembly.
> ...
> For right now, we could probably remove this snippet of code altogether
> until we engineer a more efficient way of ordering the data and metadata
> writes.
OK... It'll probably make the fs faster ;) I'll assume that
you will raise the patch. Thanks.
-
_______________________________________________
Jfs-discussion mailing list
[EMAIL PROTECTED]
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
