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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |