All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: mpatocka@redhat.com, xfs@oss.sgi.com
Subject: Re: [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing
Date: Mon, 16 Mar 2009 21:45:37 +1100	[thread overview]
Message-ID: <20090316104537.GH26138@disturbed> (raw)
In-Reply-To: <20090316090847.GA2636@infradead.org>

On Mon, Mar 16, 2009 at 05:08:47AM -0400, Christoph Hellwig wrote:
> On Sun, Mar 15, 2009 at 10:31:43PM +1100, Dave Chinner wrote:
> > index 5aeb777..08be36d 100644
> > --- a/fs/xfs/linux-2.6/xfs_fs_subr.c
> > +++ b/fs/xfs/linux-2.6/xfs_fs_subr.c
> > @@ -74,14 +74,14 @@ xfs_flush_pages(
> >  
> >  	if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) {
> >  		xfs_iflags_clear(ip, XFS_ITRUNCATED);
> > -		ret = filemap_fdatawrite(mapping);
> > -		if (flags & XFS_B_ASYNC)
> > -			return -ret;
> > -		ret2 = filemap_fdatawait(mapping);
> > -		if (!ret)
> > -			ret = ret2;
> > +		ret = -filemap_fdatawrite(mapping);
> >  	}
> > -	return -ret;
> > +	if (flags & XFS_B_ASYNC)
> > +		return ret;
> > +	ret2 = xfs_wait_on_pages(ip, first, last);
> > +	if (!ret)
> > +		ret = ret2;
> > +	return ret;
> >  }
> 
> How does this belong into this patch series?

So xfs_flush_pages waits on writeback pages which aren't caught by
mapping_tagged(mapping, PAGECACHE_TAG_DIRTY). If we are waiting for
a flush to complete, we should be waiting for all pages under IO to
complete regardless of whether there are dirty pages or not. That
matters if we are doing 2 passes to flush everything and then wait;
the wait won't see dirty mappings, but there might still be pages
under IO....

> Also I think the sync code should just use filemap_fdatawait and
> filemap_fdatawait directly.  It's at a high enough level that we don't
> need all these obsfucations.

OK. I'll rework it so that:

> > +		if (flags & SYNC_DELWRI) {
> > +			if (VN_DIRTY(inode)) {
> > +				if (flags & SYNC_TRYLOCK) {
> > +					if (xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED))
> > +						lock_flags |= XFS_IOLOCK_SHARED;
> > +				} else {
> > +					xfs_ilock(ip, XFS_IOLOCK_SHARED);
> > +					lock_flags |= XFS_IOLOCK_SHARED;
> > +				}
> 
> > +				if (lock_flags & XFS_IOLOCK_SHARED) {
> 
> Too long line and pretty ugly use of the lock_flags variable, but given
> that it gets sorted out in the sync series I think we can leave it that way.

This gets done early and the later patches become simpler.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

  reply	other threads:[~2009-03-16 10:51 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-15 11:31 [PATCH 0/5, RESEND] [XFS] Spurious ENOSPC fixes Dave Chinner
2009-03-15 11:31 ` [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Dave Chinner
2009-03-16  9:08   ` Christoph Hellwig
2009-03-16 10:45     ` Dave Chinner [this message]
2009-03-15 11:31 ` [PATCH 2/5] [XFS] Make inode flush at ENOSPC synchronous Dave Chinner
2009-03-16  9:12   ` Christoph Hellwig
2009-03-16 10:46     ` Dave Chinner
2009-03-15 11:31 ` [PATCH 3/5] [XFS] Block callers of xfs_flush_inodes() correctly Dave Chinner
2009-03-16  9:13   ` Christoph Hellwig
2009-03-16 10:27     ` Dave Chinner
2009-03-17 13:15     ` Mikulas Patocka
2009-03-15 11:31 ` [PATCH 4/5] [XFS] Flush delayed allcoation blocks on ENOSPC in create Dave Chinner
2009-03-16  9:14   ` Christoph Hellwig
2009-03-15 11:31 ` [PATCH 5/5] [XFS] Remove xfs_flush_space Dave Chinner
2009-03-16  9:15   ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2009-03-15 10:57 [PATCH 0/5] [XFS] Spurious ENOSPC fixes Dave Chinner
2009-03-15 10:57 ` [PATCH 1/5] [XFS] Use xfs_sync_inodes() for device flushing Dave Chinner
2009-03-17 13:08   ` Mikulas Patocka
2009-03-18  4:17     ` Dave Chinner
2009-03-18 16:14       ` Mikulas Patocka
2009-03-20  4:30         ` Dave Chinner
2009-03-25 15:19           ` Mikulas Patocka

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=20090316104537.GH26138@disturbed \
    --to=david@fromorbit.com \
    --cc=hch@infradead.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.