From: Dave Chinner <david@fromorbit.com>
To: Ben Myers <bpm@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 03/18] xfs: Do background CIL flushes via a workqueue
Date: Mon, 30 Apr 2012 16:09:13 +1000 [thread overview]
Message-ID: <20120430060913.GJ7015@dastard> (raw)
In-Reply-To: <20120430012432.GE3283@dastard>
On Mon, Apr 30, 2012 at 11:24:32AM +1000, Dave Chinner wrote:
> On Wed, Apr 18, 2012 at 11:47:06AM +1000, Dave Chinner wrote:
> > On Tue, Apr 17, 2012 at 04:49:56PM -0500, Ben Myers wrote:
> > > On Tue, Apr 17, 2012 at 04:21:55PM -0500, Ben Myers wrote:
> > > > Gah! I just hit this assert.
> > > >
> > > > v3.4-rc2-3-g8a00ebe with:
> > > > Christoph's ilock series
> > > > Christoph's xfsbufd series
> > > > Jan's freeze series
> > > > Dave's queue.
> > > >
> > > > nfs7 login: [ 1175.172406] XFS: Assertion failed: push_seq > 0 && push_seq <= ctx->sequence, file: /root/xfs/fs/xfs/xfs_log_cil.c, line: 406
> >
> > which has probably resulted in a log corruption.
> >
> > > [ 390.097633] ---[ end trace 33a9795b638157b9 ]---
> > >
> > > Here it is from the system log
> > >
> > > Apr 17 16:35:12 linux kernel: [ 389.637543] XFS (264=211361P۔300): Mounting Filesystem
> > > Apr 17 16:35:12 linux kernel: [ 389.912402] XFS (264=211361P۔300): Starting recovery (logdev: internal)
> > > Apr 17 16:35:12 linux kernel: [ 390.054357] XFS (264=211361P۔300): xlog_recover_inode_pass2: Bad inode magic number, dip = 0xf0ffd800, dino bp = 0xef89c480, ino = 25541592
> > > Apr 17 16:35:12 linux kernel: [ 390.066290] XFS (264=211361P۔300): Internal error xlog_recover_inode_pass2(1) at line 2248 of file /root/xfs/fs/xfs/xfs_log_recover.c. Caller 0xfaa08ffa
> >
> > Because log recovery has read a bad inode from disk, which means an
> > allocation transaction has probably not been replayed.
>
> Just as a note - I'm getting itest 121 reliably tripping over this
> exact problem as a result of the discontiguous buffer item support
> patch. Basically the problem is that an inode modification
> transaction is being replayed before the inode buffer allocation
> transaction, so the read of the inode buffer returns an
> uninitialised data area, and hence the assert failure.
>
> At this point I can't see why that patch would cause the problem to
> occur and this tends to imply that it isn't that patch that has
> caused the bug.
The bug was in my code - the calculation for the map size was wrong
so only the first half of the modifications to the buffer was being
replayed. So, this seems unrelated.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-04-30 6:09 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-13 12:10 [PATCH 0/18] xfs: current patch queue Dave Chinner
2012-04-13 12:10 ` [PATCH 01/18] xfs: Ensure inode reclaim can run during quotacheck Dave Chinner
2012-04-13 18:01 ` Mark Tinguely
2012-04-29 21:37 ` Christoph Hellwig
2012-04-13 12:10 ` [PATCH 02/18] xfs: pass shutdown method into xfs_trans_ail_delete_bulk Dave Chinner
2012-04-13 17:40 ` Mark Tinguely
2012-04-13 23:04 ` Dave Chinner
2012-04-13 23:38 ` [PATCH 02/18 V2] " Dave Chinner
2012-04-16 18:49 ` Mark Tinguely
2012-04-13 12:10 ` [PATCH 03/18] xfs: Do background CIL flushes via a workqueue Dave Chinner
2012-04-17 17:54 ` Mark Tinguely
2012-04-17 21:21 ` Ben Myers
2012-04-17 21:49 ` Ben Myers
2012-04-18 1:47 ` Dave Chinner
2012-04-30 1:24 ` Dave Chinner
2012-04-30 6:09 ` Dave Chinner [this message]
2012-04-18 1:58 ` Dave Chinner
2012-04-13 12:10 ` [PATCH 04/18] xfs: page type check in writeback only checks last buffer Dave Chinner
2012-04-16 16:15 ` Mark Tinguely
2012-04-29 21:39 ` Christoph Hellwig
2012-04-30 0:29 ` Dave Chinner
2012-04-13 12:10 ` [PATCH 05/18] xfs: Use preallocation for inodes with extsz hints Dave Chinner
2012-04-13 16:45 ` Mark Tinguely
2012-04-16 15:59 ` Mark Tinguely
2012-04-13 12:10 ` [PATCH 06/18] xfs: fix buffer lookup race on allocation failure Dave Chinner
2012-04-13 18:32 ` Mark Tinguely
2012-04-13 12:10 ` [PATCH 07/18] xfs: check for buffer errors before waiting Dave Chinner
2012-04-13 17:56 ` Mark Tinguely
2012-04-13 12:10 ` [PATCH 08/18] xfs: fix incorrect b_offset initialisation Dave Chinner
2012-04-13 12:10 ` [PATCH 09/18] xfs: use kmem_zone_zalloc for buffers Dave Chinner
2012-04-13 12:10 ` [PATCH 10/18] xfs: clean up buffer get/read call API Dave Chinner
2012-04-13 12:10 ` [PATCH 11/18] xfs: kill b_file_offset Dave Chinner
2012-04-13 12:10 ` [PATCH 12/18] xfs: use blocks for counting length of buffers Dave Chinner
2012-04-13 12:10 ` [PATCH 13/18] xfs: use blocks for storing the desired IO size Dave Chinner
2012-04-13 12:10 ` [PATCH 14/18] xfs: kill xfs_buf_btoc Dave Chinner
2012-04-13 12:10 ` [PATCH 15/18] xfs: kill XBF_LOCK Dave Chinner
2012-04-13 21:20 ` Mark Tinguely
2012-04-13 12:10 ` [PATCH 16/18] xfs: kill xfs_read_buf() Dave Chinner
2012-04-13 12:11 ` [PATCH 17/18] xfs: kill XBF_DONTBLOCK Dave Chinner
2012-04-16 14:34 ` Mark Tinguely
2012-04-13 12:11 ` [PATCH 18/18] xfs: use iolock on XFS_IOC_ALLOCSP calls Dave Chinner
2012-04-16 15:10 ` Mark Tinguely
2012-04-16 21:29 ` [PATCH 0/18] xfs: current patch queue Ben Myers
2012-04-17 4:12 ` Dave Chinner
2012-04-17 14:44 ` Ben Myers
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=20120430060913.GJ7015@dastard \
--to=david@fromorbit.com \
--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