public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 06/13] xfs: xfs_sync_data is redundant.
Date: Wed, 3 Oct 2012 06:51:24 +1000	[thread overview]
Message-ID: <20121002205124.GS23520@dastard> (raw)
In-Reply-To: <506AE5AD.60509@redhat.com>

On Tue, Oct 02, 2012 at 09:01:33AM -0400, Brian Foster wrote:
> On 10/01/2012 08:44 PM, Brian Foster wrote:
> > On 10/01/2012 08:10 PM, Dave Chinner wrote:
> ...
> > 
> > I gave this a quick couple runs against 273 and it passes (on top of
> > the entire die-xfssyncd-die patchset). I'll kick off another full run
> > on this box overnight. Thanks!
> > 
> 
> And I spoke a bit too soon... I hit the following warning with this change:
> 
> WARNING: at fs/fs-writeback.c:1401 sync_inodes_sb+0xc0/0xd0()
> 
> The inline patch addresses it. I also see the following message during
> 273 but it doesn't appear related to this set:
> 
> kernel: XFS (dm-4): xlog_verify_grant_tail: space > BBTOB(tail_blocks)
> 
> Brian
> 
> diff --git a/fs/xfs/xfs_inode.h b/fs/xfs/xfs_inode.h
> index da69c18..f11133b 100644
> --- a/fs/xfs/xfs_inode.h
> +++ b/fs/xfs/xfs_inode.h
> @@ -294,7 +294,9 @@ xfs_new_eof(struct xfs_inode *ip, xfs_fsize_t new_size)
>  static inline void
>  xfs_flush_inodes(struct xfs_inode *ip)
>  {
> -	writeback_inodes_sb_if_idle(VFS_I(ip)->i_sb, WB_REASON_FS_FREE_SPACE);
> +	down_read(&VFS_I(ip)->i_sb->s_umount);
> +	sync_inodes_sb(VFS_I(ip)->i_sb);
> +	up_read(&VFS_I(ip)->i_sb->s_umount);
>  }

I don't think we can do an unconditional down_read() there, as the
caller from xfs_create() already holds an i_mutex (the VFS holds the
directory inode lock) and I'm pretty sure that s_umount is supposed
to be outside per-inode locks.

Given that where we are called we are inside a transaction for the
create case, and inside mnt_want_write() protection for the buffered
write case, the likelyhood of s_umount being held for write at
ENOSPC is going to be non-existent at these call sites. Hence a
down_read_trylock() will avoid lock ordering issues, but will almost
always succeed and so be equivalent to down_read()....

/me modifies and runs 273 and the enospc xfstests group...

Seems to work just fine, and no warnings. Patch below.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

xfs: make inode writeback at ENOSPC blocking.

From: Dave Chinner <dchinner@redhat.com>

writeback_inodes_sb_if_idle() is not sufficient to trigger delalloc
conversion fast enough to prevent spurious ENOSPC whent here are
hundreds of writers, thousands of small files and GBs of free RAM.
Change this to use sync_sb_inodes() to block callers while we wait
for writeback like the previous xfs_flush_inodes implementation did.

We have to hold the s_umount lock here, but because this call can
nest inside i_mutex (the parent directory in the create case, held
by the VFS), we have to use down_read_trylock() to avoid potential
deadlocks. In practice, this trylock will succeed on almost every
attempt as unmount/remount type operations are exceedingly rare.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
 fs/xfs/xfs_inode.h |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_inode.h b/fs/xfs/xfs_inode.h
index da69c18..b3dabe9 100644
--- a/fs/xfs/xfs_inode.h
+++ b/fs/xfs/xfs_inode.h
@@ -294,7 +294,12 @@ xfs_new_eof(struct xfs_inode *ip, xfs_fsize_t new_size)
 static inline void
 xfs_flush_inodes(struct xfs_inode *ip)
 {
-	writeback_inodes_sb_if_idle(VFS_I(ip)->i_sb, WB_REASON_FS_FREE_SPACE);
+	struct super_block *sb = VFS_I(ip)->i_sb;
+
+	if (down_read_trylock(&sb->s_umount)) {
+		sync_inodes_sb(sb);
+		up_read(&sb->s_umount);
+	}
 }
 
 /*

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2012-10-02 20:50 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-28  4:44 [PATCH V3 00/13] xfs: remove the xfssyncd mess Dave Chinner
2012-09-28  4:44 ` [PATCH 01/13] xfs: xfs_syncd_stop must die Dave Chinner
2012-09-28  4:44 ` [PATCH 02/13] xfs: rationalise xfs_mount_wq users Dave Chinner
2012-09-28 12:27   ` Christoph Hellwig
2012-09-28  4:44 ` [PATCH 03/13] xfs: don't run the sync work if the filesystem is read-only Dave Chinner
2012-09-28 12:27   ` Christoph Hellwig
2012-09-28  4:44 ` [PATCH 04/13] xfs: sync work is now only periodic log work Dave Chinner
2012-09-28 12:31   ` Christoph Hellwig
2012-09-28  4:44 ` [PATCH 05/13] xfs: Bring some sanity to log unmounting Dave Chinner
2012-09-28  4:44 ` [PATCH 06/13] xfs: xfs_sync_data is redundant Dave Chinner
2012-09-28 12:34   ` Christoph Hellwig
2012-10-01 17:44     ` Ben Myers
2012-10-02  0:14       ` Dave Chinner
2012-10-02 19:39         ` Ben Myers
2012-09-28 21:44   ` Mark Tinguely
2012-10-01 20:14   ` Brian Foster
2012-10-01 21:31     ` Mark Tinguely
2012-10-02  0:10     ` Dave Chinner
2012-10-02  0:44       ` Brian Foster
2012-10-02 13:01         ` Brian Foster
2012-10-02 20:51           ` Dave Chinner [this message]
2012-10-02 21:13             ` Brian Foster
2012-10-04  0:05             ` Ben Myers
2012-10-04  1:07               ` Dave Chinner
2012-10-02 13:22       ` Christoph Hellwig
2012-10-02 20:24         ` Dave Chinner
2012-10-02 20:25     ` Ben Myers
2012-09-28  4:44 ` [PATCH 07/13] xfs: syncd workqueue is no more Dave Chinner
2012-09-28 12:35   ` Christoph Hellwig
2012-09-28 18:17   ` Mark Tinguely
2012-10-01 17:54     ` Ben Myers
2012-09-28  4:44 ` [PATCH 08/13] xfs: xfs_sync_fsdata is redundant Dave Chinner
2012-09-28  4:44 ` [PATCH 09/13] xfs: move xfs_quiesce_attr() into xfs_super.c Dave Chinner
2012-09-28  4:44 ` [PATCH 10/13] xfs: xfs_quiesce_attr() should quiesce the log like unmount Dave Chinner
2012-09-28  4:44 ` [PATCH 11/13] xfs: rename xfs_sync.[ch] to xfs_icache.[ch] Dave Chinner
2012-09-28  4:44 ` [PATCH 12/13] xfs: move inode locking functions to xfs_inode.c Dave Chinner
2012-09-28  4:44 ` [PATCH 13/13] xfs: remove xfs_iget.c Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121002205124.GS23520@dastard \
    --to=david@fromorbit.com \
    --cc=bfoster@redhat.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox