All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: spurious -ENOSPC on XFS
Date: Wed, 21 Jan 2009 10:24:22 +1100	[thread overview]
Message-ID: <20090120232422.GF10158@disturbed> (raw)
In-Reply-To: <Pine.LNX.4.64.0901201430250.4603@hs20-bc2-1.build.redhat.com>

On Tue, Jan 20, 2009 at 02:38:27PM -0500, Mikulas Patocka wrote:
> 
> 
> On Sun, 18 Jan 2009, Christoph Hellwig wrote:
> 
> > On Tue, Jan 13, 2009 at 11:28:58PM -0500, Mikulas Patocka wrote:
> > > The result must not depend on magic timer values. If it does, you end up 
> > > with undebbugable nondeterministic failures.
> > > 
> > > Why don't you change that 500ms wait to "wait until the flush finishes"? 
> > > That would be correct.
> > 
> > Yes, this probably would better.  Could I motivate you to come up with
> > a patch for that?
> > 
> 
> Hi
> 
> I looked at the source and found out that it uses sync_blockdev for 
> syncing --- but sync_blockdev writes only metadata buffers, it doesn't 
> touch inodes and pages and doesn't resolve delayed allocations. So it 
> really doesn't sync anything.

Ah, bugger. Thanks for finding this.

> I replaced it with correct syncing of all inodes. With this patch it 
> passes my testcase (no more spurious -ENOSPCs), but it still isn't 
> correct, there is that 500ms delay --- if the machine was so overloaded 
> that it couldn't sync withing 500ms, you still get spurious -ENOSPC.

That's VFS level data syncing - there may be other XFS level stuff
that can be dones as well (e.g. cleanup/truncate of unlinked inodes)
that will release space.

> There are notions about possible deadlocks (the syncer may lock against 
> the process that is waiting for the sync to finish), that's why removing 
> that 500ms delay isn't that easy as it seems. I don't have XFS knowledge 
> to check for the deadlocks, it should be done by XFS developers. Also, 
> when you resolve the deadlocks and drop the timeout, replace WB_SYNC_NONE 
> with WB_SYNC_ALL in this patch.

Right, so you need to use internal xfs sync functions that don't
have these problems. That is:

	error = xfs_sync_inodes(ip->i_mount, SYNC_DELWRI|SYNC_WAIT);

will do a blocking flush of all the inodes without deadlocks occurring.
Then you can remove the 500ms wait.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	xfs@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: spurious -ENOSPC on XFS
Date: Wed, 21 Jan 2009 10:24:22 +1100	[thread overview]
Message-ID: <20090120232422.GF10158@disturbed> (raw)
In-Reply-To: <Pine.LNX.4.64.0901201430250.4603@hs20-bc2-1.build.redhat.com>

On Tue, Jan 20, 2009 at 02:38:27PM -0500, Mikulas Patocka wrote:
> 
> 
> On Sun, 18 Jan 2009, Christoph Hellwig wrote:
> 
> > On Tue, Jan 13, 2009 at 11:28:58PM -0500, Mikulas Patocka wrote:
> > > The result must not depend on magic timer values. If it does, you end up 
> > > with undebbugable nondeterministic failures.
> > > 
> > > Why don't you change that 500ms wait to "wait until the flush finishes"? 
> > > That would be correct.
> > 
> > Yes, this probably would better.  Could I motivate you to come up with
> > a patch for that?
> > 
> 
> Hi
> 
> I looked at the source and found out that it uses sync_blockdev for 
> syncing --- but sync_blockdev writes only metadata buffers, it doesn't 
> touch inodes and pages and doesn't resolve delayed allocations. So it 
> really doesn't sync anything.

Ah, bugger. Thanks for finding this.

> I replaced it with correct syncing of all inodes. With this patch it 
> passes my testcase (no more spurious -ENOSPCs), but it still isn't 
> correct, there is that 500ms delay --- if the machine was so overloaded 
> that it couldn't sync withing 500ms, you still get spurious -ENOSPC.

That's VFS level data syncing - there may be other XFS level stuff
that can be dones as well (e.g. cleanup/truncate of unlinked inodes)
that will release space.

> There are notions about possible deadlocks (the syncer may lock against 
> the process that is waiting for the sync to finish), that's why removing 
> that 500ms delay isn't that easy as it seems. I don't have XFS knowledge 
> to check for the deadlocks, it should be done by XFS developers. Also, 
> when you resolve the deadlocks and drop the timeout, replace WB_SYNC_NONE 
> with WB_SYNC_ALL in this patch.

Right, so you need to use internal xfs sync functions that don't
have these problems. That is:

	error = xfs_sync_inodes(ip->i_mount, SYNC_DELWRI|SYNC_WAIT);

will do a blocking flush of all the inodes without deadlocks occurring.
Then you can remove the 500ms wait.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2009-01-20 23:24 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-12 11:14 spurious -ENOSPC on XFS Mikulas Patocka
2009-01-12 11:14 ` Mikulas Patocka
2009-01-12 15:11 ` Christoph Hellwig
2009-01-12 15:11   ` Christoph Hellwig
2009-01-13  5:58   ` Lachlan McIlroy
2009-01-13  5:58     ` Lachlan McIlroy
2009-01-14 22:16     ` Dave Chinner
2009-01-14 22:16       ` Dave Chinner
2009-01-15  0:57       ` Lachlan McIlroy
2009-01-15  0:57         ` Lachlan McIlroy
2009-01-15  8:47         ` Dave Chinner
2009-01-15  8:47           ` Dave Chinner
2009-01-13 21:49 ` Dave Chinner
2009-01-13 21:49   ` Dave Chinner
2009-01-14  4:28   ` Mikulas Patocka
2009-01-14  4:28     ` Mikulas Patocka
2009-01-18 17:31     ` Christoph Hellwig
2009-01-18 17:31       ` Christoph Hellwig
2009-01-20 19:38       ` Mikulas Patocka
2009-01-20 19:38         ` Mikulas Patocka
2009-01-20 23:24         ` Dave Chinner [this message]
2009-01-20 23:24           ` Dave Chinner
2009-01-22 20:59           ` Christoph Hellwig
2009-01-22 20:59             ` Christoph Hellwig
2009-01-22 22:43             ` Christoph Hellwig
2009-01-22 22:43               ` Christoph Hellwig
2009-01-23 20:14               ` Mikulas Patocka
2009-01-23 20:14                 ` Mikulas Patocka
2009-01-24  7:12                 ` Dave Chinner
2009-01-24  7:12                   ` Dave Chinner
2009-01-29 16:39                   ` Mikulas Patocka
2009-01-29 16:39                     ` Mikulas Patocka
2009-01-29 16:45                     ` Mikulas Patocka
2009-01-29 16:45                       ` Mikulas Patocka
2009-01-31 23:57                     ` Dave Chinner
2009-01-31 23:57                       ` Dave Chinner
2009-02-02 17:36                       ` Mikulas Patocka
2009-02-02 17:36                         ` Mikulas Patocka
2009-02-03  3:27                         ` Dave Chinner
2009-02-03  3:27                           ` Dave Chinner
2009-02-03 20:05                           ` Mikulas Patocka
2009-02-03 20:05                             ` Mikulas Patocka
2009-02-04 12:08                             ` Dave Chinner
2009-02-04 12:08                               ` Dave Chinner
2009-02-05  4:31                               ` Mikulas Patocka
2009-02-05  4:31                                 ` Mikulas Patocka
2009-02-05  7:43                                 ` Dave Chinner
2009-02-05  7:43                                   ` 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=20090120232422.GF10158@disturbed \
    --to=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpatocka@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.