All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Tinguely <tinguely@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [RFC] xfs: wait for the write of the superblock on unmount
Date: Fri, 20 Jul 2012 16:24:05 -0500	[thread overview]
Message-ID: <5009CC75.2080207@sgi.com> (raw)
In-Reply-To: <50095B77.7090203@sgi.com>

On 07/20/12 08:21, Mark Tinguely wrote:
> On 07/18/12 20:58, Dave Chinner wrote:
>> On Wed, Jul 18, 2012 at 12:33:58PM -0500, tinguely@sgi.com wrote:
>>> Sorry, I have been distracted away from this regression. This was
>>> previously
>>> titled "xfs: synchronously write the superblock on unmount".
>>>
>>> xfs_wait_buftarg() does not wait for the completion of the write of the
>>> uncached superblock. This write can race with the shutdown of the log
>>> and
>>> causes a panic if the write does not win the race.
>>>
>>> The log write of the superblock is important for possible recovery,
>>> but a
>>> second syncronous write of the same superblock seems redundant. Would
>>> just
>>> waiting for the iodone() of the log write before tearing down the log be
>>> enough?
>>
>> Yes. i.e. something like:
>>
>> /*
>> * The superblock buffer is uncached, so xfs_wait_buftarg()
>> * will not wait for it. Hence we need to explicitly wait
>> * for IO completion on the superblock to occur here.
>> */
>> error = xfs_buf_iowait(mp->m_sb_bp);
>> if (error)
>> AAAAIEEEE!
>>
>> This fix is also needed in xfs_quiesce_attr() for the freeze and
>> ro,remount cases as well.
>>
>> Cheers,
>>
>> Dave.
>>
>
> Thanks for the feedback.
>
> I chose the ugly lock to block on the superblock buffer because it has
> XBF_ASYNC set at that point and won't go through the complete() patch. I
> will look at turning the XBF_ASYNC flag off and wait on a xfs_buf_iowait().
>
> --Mark.

Looks like the xfsaild_push() sets the XBF_ASYNC flag on the superblock 
buffer. Waiting on the xfs_buf_iowait() won't work but have to use the 
less elegant lock.

--Mark.

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

  reply	other threads:[~2012-07-20 21:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20120717215957.855744999@tinguelysgi.com>
2012-07-18 17:33 ` [RFC] xfs: wait for the write of the superblock on unmount tinguely
2012-07-19  1:58   ` Dave Chinner
2012-07-20 13:21     ` Mark Tinguely
2012-07-20 21:24       ` Mark Tinguely [this message]
2012-07-24 13:57   ` Christoph Hellwig
2012-07-24 14:03     ` Mark Tinguely

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=5009CC75.2080207@sgi.com \
    --to=tinguely@sgi.com \
    --cc=david@fromorbit.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.