All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Myers <bpm@sgi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 1/5] [PATCH] xfs: fix attr2 vs large data fork assert
Date: Tue, 29 Nov 2011 12:48:16 -0600	[thread overview]
Message-ID: <20111129184816.GV29840@sgi.com> (raw)
In-Reply-To: <20111117073004.GB3733@infradead.org>

Hey Christoph,

On Thu, Nov 17, 2011 at 02:30:04AM -0500, Christoph Hellwig wrote:
> On Thu, Nov 17, 2011 at 10:15:17AM +1100, Dave Chinner wrote:
> > On Tue, Nov 15, 2011 at 03:14:08PM -0500, Christoph Hellwig wrote:
> > > With Dmitry fsstress updates I've seen very reproducible crashes in
> > > xfs_attr_shortform_remove because xfs_attr_shortform_bytesfit claims that
> > > the attributes would not fit inline into the inode after removing an
> > > attribute.  It turns out that we were operating on an inode with lots
> > > of delalloc extents, and thus an if_bytes values for the data fork that
> > > is larger than biggest possible on-disk storage for it which utterly
> > > confuses the code near the end of xfs_attr_shortform_bytesfit.
> > 
> > We have a test that stresses allocated extents vs attributes in the
> > xfs_fsr swapext test (227), but that does not take into account
> > delalloc extents. It sounds like it would be relatively easy to
> > write a regression test for this particular case - create a file
> > with a bunch of attributes, then create a number of delalloc data
> > extents, then remove the attributes to trigger the condition in
> > xfs_attr_shortform_remove()....
> 
> Test 117 with Dmitries new fsstress changes hit it 100% reliably
> before
> 
> 	xfstests: freeze fsstress options for 117'th
>
> I was planning on adding a copy of the test using an explicit
> combination of fsstress seeds that reproduce the issue.

FYI, Test 117 also hit it for me after I backed off 'freeze fsstress
options'.  Are you still planning on adding a copy of the test with the
seeds in question?

Thanks,
	Ben

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

  reply	other threads:[~2011-11-29 18:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-15 20:14 [PATCH 0/5] for-3.2 queue Christoph Hellwig
2011-11-15 20:14 ` [PATCH 1/5] [PATCH] xfs: fix attr2 vs large data fork assert Christoph Hellwig
2011-11-16 23:15   ` Dave Chinner
2011-11-17  7:30     ` Christoph Hellwig
2011-11-29 18:48       ` Ben Myers [this message]
2011-11-29 18:55         ` Christoph Hellwig
2011-11-19 17:44   ` [PATCH v2] " Christoph Hellwig
2011-11-15 20:14 ` [PATCH 2/5] xfs: use per-filesystem I/O completion workqueues Christoph Hellwig
2011-11-16 19:01   ` Ben Myers
2011-11-17  7:40     ` Christoph Hellwig
2011-11-16 23:24   ` Dave Chinner
2011-11-17  7:25     ` Christoph Hellwig
2011-11-15 20:14 ` [PATCH 3/5] xfs: do not require an ioend for new EOF calculation Christoph Hellwig
2011-11-16 18:09   ` Ben Myers
2011-11-16 23:28   ` Dave Chinner

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=20111129184816.GV29840@sgi.com \
    --to=bpm@sgi.com \
    --cc=hch@infradead.org \
    --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.