From: Christoph Hellwig <hch@infradead.org>
To: Ben Myers <bpm@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: shutdown xfs_sync_worker before the log
Date: Wed, 20 Jun 2012 03:36:00 -0400 [thread overview]
Message-ID: <20120620073600.GA4399@infradead.org> (raw)
In-Reply-To: <20120525204536.GA4721@sgi.com>
On Fri, May 25, 2012 at 03:45:36PM -0500, Ben Myers wrote:
> Hey Dave,
>
> On Thu, May 24, 2012 at 05:39:52PM -0500, Ben Myers wrote:
> > Anyway, I'll make some time to work on this tomorrow so I can test it over
> > the weekend.
>
> This is going to spin over the weekend. See what you think.
>
> -----------
>
> xfs: shutdown xfs_sync_worker before the log
>
> Revert commit 1307bbd, which uses the s_umount semaphore to provide
> exclusion between xfs_sync_worker and unmount, in favor of shutting down
> the sync worker before freeing the log in xfs_log_unmount. This is a
> cleaner way of resolving the race between xfs_sync_worker and unmount
> than using s_umount.
I like the cancel_delayed_work_sync on unmount side of this, but I don't
really like the MS_ACTIVE check - why can't we only do the initial
xfs_syncd_queue_sync as the last thing in the mount process?
On just slightly related issue with m_sync_work: what does the force
flush of it from xfs_fs_sync_fs in laptop mode buys us? The sync
just did the log_force and log coverage, so the only think it will do
is force out the AIL after we did the log force and thus guarantee to
keep the fs busy for a while. I can't really see how that's actually
useful for batter life. Note that ->sync_fs is only called for an
epxlicit sync (in addition to umount,remount ro and freeze), so for
normal desktop operation it's entirely irrelevant anyway.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-06-20 7:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-23 17:43 BUG in xlog_get_lowest_lsn Ben Myers
2012-05-14 20:34 ` [PATCH] xfs: use s_umount sema in xfs_sync_worker Ben Myers
2012-05-15 18:30 ` Mark Tinguely
2012-05-15 19:06 ` Ben Myers
2012-05-16 1:56 ` Dave Chinner
2012-05-16 17:04 ` Ben Myers
2012-05-17 7:16 ` Dave Chinner
2012-05-23 9:02 ` Dave Chinner
2012-05-23 16:45 ` Ben Myers
2012-05-24 22:39 ` Ben Myers
2012-05-25 20:45 ` [PATCH] xfs: shutdown xfs_sync_worker before the log Ben Myers
2012-05-29 15:07 ` Ben Myers
2012-05-29 15:36 ` Brian Foster
2012-05-29 17:04 ` Ben Myers
2012-05-29 17:54 ` Brian Foster
2012-05-31 16:23 ` Mark Tinguely
2012-06-06 4:26 ` Dave Chinner
2012-06-11 20:45 ` Ben Myers
2012-06-11 21:11 ` Mark Tinguely
2012-06-11 23:36 ` Dave Chinner
2012-06-14 17:13 ` Mark Tinguely
2012-06-14 23:56 ` Dave Chinner
2012-06-20 7:44 ` Christoph Hellwig
2012-06-20 7:36 ` Christoph Hellwig [this message]
2012-06-20 17:18 ` Ben Myers
2012-06-20 22:59 ` Dave Chinner
2012-06-21 7:12 ` Christoph Hellwig
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=20120620073600.GA4399@infradead.org \
--to=hch@infradead.org \
--cc=bpm@sgi.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