On Sun, Dec 18, 2011 at 10:49:55AM -0500, Christoph Hellwig wrote:
> If the writeback code writes back an inode because it has expired we currently
> use the non-blockin ->write_inode path. This means any inode that is pinned
> is skipped. With delayed logging and a workload that has very little log
> traffic otherwise it is very likely that an inode that gets constantly
> written to is always pinned, and thus we keep refusing to write it. The VM
> writeback code at that point redirties it and doesn't try to write it again
> for another 30 seconds. This means under certain scenarious time based
> metadata writeback never happens.
>
> Fix this by calling into xfs_log_inode for kupdate in addition to data
> integrity syncs, and thus transfer the inode to the log ASAP.
>
> Signed-off-by: Christoph Hellwig <hch@xxxxxx>
>
> Index: xfs/fs/xfs/xfs_super.c
> ===================================================================
> --- xfs.orig/fs/xfs/xfs_super.c 2011-12-14 05:33:07.193262189 -0800
> +++ xfs/fs/xfs/xfs_super.c 2011-12-14 05:38:56.108038623 -0800
> @@ -905,7 +884,7 @@ xfs_fs_write_inode(
I could not reproduce a situation where this was called with for_kupdate
set and the inode was pinned for very long. I'm curious if there was an
easy workload to reproduce this.
> if (!ip->i_update_core)
> return 0;
>
> - if (wbc->sync_mode == WB_SYNC_ALL) {
> + if (wbc->sync_mode == WB_SYNC_ALL || wbc->for_kupdate) {
It looks to me that this is the relevant codepath:
bdi_writeback_thread .or. bdi_forker_thread
wb_do_writeback
wb_check_old_data_flush
wb_writeback
writeback_sb_inodes
writeback_single_inode
write_inode
.write_inode
xfs_fs_write_inode
AFAICS the only place that for_kupdate is set is in
wb_check_old_data_flush.
Reviewed-by: Mark Tinguely <tinguely@xxxxxxx>
Reviewed-by: Ben Myers <bpm@xxxxxxx>
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
