public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Donald Douwsma <donaldd@sgi.com>
To: Christoph Hellwig <hch@infradead.org>,
	Lachlan McIlroy <lachlan@sgi.com>,
	xfs@oss.sgi.com
Subject: Re: Assertion failed: atomic_read(&mp->m_active_trans)
Date: Thu, 04 Dec 2008 16:36:43 +1100	[thread overview]
Message-ID: <49376C6B.7070100@sgi.com> (raw)
In-Reply-To: <20081203213950.GX18236@disturbed>

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

Dave Chinner wrote:
> On Wed, Dec 03, 2008 at 05:48:49AM -0500, Christoph Hellwig wrote:
>> I'd rather fix it properly.
> 
> Sure, but in the mean time, I'd suggest changing it to a WARN_ON()
> rather than an ASSERT(). That way we'll continue to have ppl bug us
> about it until the VFS can support read-only remounts without racing
> correctly.

That sounds like a much better idea.

Unfortunately we wont get feedback when people hit this on the root fs
unless they have serial consoles (since /var/log/... has gone away by then).

> Has that work been dropped on the floor, Christoph? We'vecat 
> been holding off removing this ASSERT or adding the hack
> I did to work around the common case of the assert triggering
> based on the fact that the problem in the VFS would be fixed
> in the next release. That was the case each release since
> 2.6.25 and there doesn't seem to be much progress...
> 
>> Do you guys have a somewhat reliable
>> testcase hitting it?
> 
> I used to have one of the xfsqa tests hit it every so often,
> but not what you'd call reliably....

Indeed, we dont hit this in regular qa. I guess most qa scripts dont
specifically exercise remount readonly wile stressing the filesystem.
The few occasions we have hit it were when rebooting in between test
runs when the root fs was xfs.

Don






[-- Attachment #2: warn-if-transactions-are-in-flight-on-remount-ro --]
[-- Type: text/plain, Size: 430 bytes --]


--- a/fs/xfs/linux-2.6/xfs_sync.c
+++ b/fs/xfs/linux-2.6/xfs_sync.c
@@ -371,7 +371,7 @@ xfs_quiesce_attr(
        /* flush inodes and push all remaining buffers out to disk */
        xfs_quiesce_fs(mp);
 
-       ASSERT_ALWAYS(atomic_read(&mp->m_active_trans) == 0);
+       WARN_ON(atomic_read(&mp->m_active_trans) == 0);
 
        /* Push the superblock and write an unmount record */
        error = xfs_log_sbcount(mp, 1);


[-- Attachment #3: Type: text/plain, Size: 121 bytes --]

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

  reply	other threads:[~2008-12-04  5:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-25  8:00 Assertion failed: atomic_read(&mp->m_active_trans) Donald Douwsma
2008-12-02  3:25 ` Lachlan McIlroy
2008-12-03 10:48   ` Christoph Hellwig
2008-12-03 21:39     ` Dave Chinner
2008-12-04  5:36       ` Donald Douwsma [this message]
2008-12-04 12:33       ` 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=49376C6B.7070100@sgi.com \
    --to=donaldd@sgi.com \
    --cc=hch@infradead.org \
    --cc=lachlan@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