On Sunday 18 December 2011, 16:49:55 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.
Wouldn't this qualify as STABLE material then?
> 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(
> if (!ip->i_update_core)
> return 0;
>
> - if (wbc->sync_mode == WB_SYNC_ALL) {
> + if (wbc->sync_mode == WB_SYNC_ALL || wbc->for_kupdate) {
> /*
> * Make sure the inode has made it it into the log. Instead
> * of forcing it all the way to stable storage using a
>
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
