Re: [Ext2-devel] OOM problems still left in 2.6.13-rc3

[Andreas Dilger <adilger@clusterfs.com>]

On Jul 29, 2005  21:36 +0900, Takashi Sato wrote:
> The buffers connected to t_sync_datalist can't simply be removed like
> the buffers connected to t_locked_list, since we don't know if the
> I/O against the buffers are complete.
> 
> So we should wait until the committing transaction becomes complete
> if there are any buffers connected to the transaction's
> t_sync_datalist.
> 
> b) If journal_unmap_buffer() returns -1 on journal_invalidatepages(),
>   call log_wait_commit() to wait for the completion of the
>   transaction, and retry to call journal_unmap_buffer() again.
>
> @@ -1899,8 +1896,19 @@ int journal_invalidatepage(journal_t *jo
> 
>   if (offset <= curr_off) {
>     /* This block is wholly outside the truncation point */
> +retry:
>    lock_buffer(bh);
> -   may_free &= journal_unmap_buffer(journal, bh);
> +   ret = journal_unmap_buffer(journal, bh, &wait_tid);
> +   /* When this buffer is in transaction of
> +    * t_sync_datalist, truncate must wait for
> +    * that transaction.
> +    */
> +   if (ret < 0) {
> +    unlock_buffer(bh);
> +    log_wait_commit(journal, wait_tid);
> +    goto retry;
> +   }
> +   may_free &= ret;

What kind of effect does this have on filesystem performance?
This would apparently make truncate be synchronous with journal commit due to
truncate_{partial,complete}_page->do_invalidatepage->journal_invalidatepage().

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/