Re: [RFC PATCH 2/2] jbd: Stabilize pages during writes when inordered mode

[Jan Kara]

On Wed 21-11-12 18:36:45, Darrick J. Wong wrote:
> When writing buffers out to disk ahead of committing a transaction, set the
> Stable bit on the page to prevent others from wandering in and modifying the
> page.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
> ---
>  fs/jbd/commit.c |   18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/jbd/commit.c b/fs/jbd/commit.c
> index 86b39b1..b1f0eed 100644
> --- a/fs/jbd/commit.c
> +++ b/fs/jbd/commit.c
> @@ -155,13 +155,29 @@ static int journal_write_commit_record(journal_t *journal,
>  	return (ret == -EIO);
>  }
>  
> +static void end_stable_write_sync(struct buffer_head *bh, int uptodate)
> +{
> +	clear_page_stable(bh->b_page);
> +	end_buffer_write_sync(bh, uptodate);
> +}
  This doesn't work when blocksize < pagesize... There can be more buffers
in one page under IO so you can clear the stable bit only after the last of
them is done. See how PageWriteback bit is handled in
end_buffer_async_write().

> +
>  static void journal_do_submit_data(struct buffer_head **wbuf, int bufs,
>  				   int write_op)
>  {
>  	int i;
>  
>  	for (i = 0; i < bufs; i++) {
> -		wbuf[i]->b_end_io = end_buffer_write_sync;
> +		struct page *p = wbuf[i]->b_page;
> +		if (TestSetPageStable(p))
> +			wbuf[i]->b_end_io = end_buffer_write_sync;
> +		else
> +			wbuf[i]->b_end_io = end_stable_write_sync;
  Umm, why is this? It presume it is some attempt to handle blocksize <
page size?

> +
> +		if (trylock_page(p)) {
> +			clear_page_dirty_for_io(p);
> +			unlock_page(p);
> +		}
> +
  And this is wrong again for blocksize < pagesize. There can be other
dirty buffers under the page...

>  		/* We use-up our safety reference in submit_bh() */
>  		submit_bh(write_op, wbuf[i]);
>  	}

								Honza
-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/