All of lore.kernel.org
 help / color / mirror / Atom feed
* xfstests 250 fail on newer kernels
@ 2012-10-19 17:37 Carlos Maiolino
  2012-10-19 21:53 ` Dave Chinner
  0 siblings, 1 reply; 5+ messages in thread
From: Carlos Maiolino @ 2012-10-19 17:37 UTC (permalink / raw)
  To: xfs

Hi,

reviewing a patch to xfstests250, I ran it against newer kernels (3.6.0+ and
3.7.0-rc1) and noticed it is failing. i.e. btree is getting corrupted. 

I'm going to take a look at it, but let me know if anybody has already
found/fixed it.

-- 
--Carlos

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: xfstests 250 fail on newer kernels
  2012-10-19 17:37 xfstests 250 fail on newer kernels Carlos Maiolino
@ 2012-10-19 21:53 ` Dave Chinner
  2012-10-20 11:24   ` Carlos Maiolino
  0 siblings, 1 reply; 5+ messages in thread
From: Dave Chinner @ 2012-10-19 21:53 UTC (permalink / raw)
  To: xfs

On Fri, Oct 19, 2012 at 02:37:30PM -0300, Carlos Maiolino wrote:
> Hi,
> 
> reviewing a patch to xfstests250, I ran it against newer kernels (3.6.0+ and
> 3.7.0-rc1) and noticed it is failing. i.e. btree is getting corrupted. 

It's been failing on mainline kernels for a long time. In fact, i
think it's been failing since it was created. But it's not failing
due to btree corruption - it's failing because mkfs is not leaving
enough space in the AG that contains the log for sanity checks to
pass. i.e. that there are always a minimum of 4 blocks of freespace
in an AG.

This is not actually a problem - the log takes the entire AG, so
allocation will never occur in it, so having less than 4 blocks of
free space in the AG is just noise in this case. It's never bubbled
to the top of my list to fix...

> I'm going to take a look at it, but let me know if anybody has already
> found/fixed it.

If it is failing the check_scratch_fs stage, then it is most likely
the above issue. The corrupted btree problem that the test was
writen for caused the system to ASSERT fail or crash - i.e. it
didn't even run to the point of checking the fs....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: xfstests 250 fail on newer kernels
  2012-10-19 21:53 ` Dave Chinner
@ 2012-10-20 11:24   ` Carlos Maiolino
  2012-10-21 22:31     ` Dave Chinner
  0 siblings, 1 reply; 5+ messages in thread
From: Carlos Maiolino @ 2012-10-20 11:24 UTC (permalink / raw)
  To: xfs

On Sat, Oct 20, 2012 at 08:53:43AM +1100, Dave Chinner wrote:
> On Fri, Oct 19, 2012 at 02:37:30PM -0300, Carlos Maiolino wrote:
> > Hi,
> > 
> > reviewing a patch to xfstests250, I ran it against newer kernels (3.6.0+ and
> > 3.7.0-rc1) and noticed it is failing. i.e. btree is getting corrupted. 
> 
> It's been failing on mainline kernels for a long time. In fact, i
> think it's been failing since it was created. But it's not failing
> due to btree corruption - it's failing because mkfs is not leaving
> enough space in the AG that contains the log for sanity checks to
> pass. i.e. that there are always a minimum of 4 blocks of freespace
> in an AG.
> 
> This is not actually a problem - the log takes the entire AG, so
> allocation will never occur in it, so having less than 4 blocks of
> free space in the AG is just noise in this case. It's never bubbled
> to the top of my list to fix...
> 
> > I'm going to take a look at it, but let me know if anybody has already
> > found/fixed it.
> 
> If it is failing the check_scratch_fs stage, then it is most likely
> the above issue. The corrupted btree problem that the test was
> writen for caused the system to ASSERT fail or crash - i.e. it
> didn't even run to the point of checking the fs....
> 
Yep, that was my point, it's failing on check_scratch_fs stage. The btree
problem has been fixed since it is not triggering the ASSERT. Didn't know it is
failing since its creation :)

I can add it to my todo list if you want some stuff out of yours

> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

-- 
--Carlos

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: xfstests 250 fail on newer kernels
  2012-10-20 11:24   ` Carlos Maiolino
@ 2012-10-21 22:31     ` Dave Chinner
  2012-10-23 12:24       ` Christoph Hellwig
  0 siblings, 1 reply; 5+ messages in thread
From: Dave Chinner @ 2012-10-21 22:31 UTC (permalink / raw)
  To: xfs

On Sat, Oct 20, 2012 at 08:24:05AM -0300, Carlos Maiolino wrote:
> On Sat, Oct 20, 2012 at 08:53:43AM +1100, Dave Chinner wrote:
> > On Fri, Oct 19, 2012 at 02:37:30PM -0300, Carlos Maiolino wrote:
> > > Hi,
> > > 
> > > reviewing a patch to xfstests250, I ran it against newer kernels (3.6.0+ and
> > > 3.7.0-rc1) and noticed it is failing. i.e. btree is getting corrupted. 
> > 
> > It's been failing on mainline kernels for a long time. In fact, i
> > think it's been failing since it was created. But it's not failing
> > due to btree corruption - it's failing because mkfs is not leaving
> > enough space in the AG that contains the log for sanity checks to
> > pass. i.e. that there are always a minimum of 4 blocks of freespace
> > in an AG.
> > 
> > This is not actually a problem - the log takes the entire AG, so
> > allocation will never occur in it, so having less than 4 blocks of
> > free space in the AG is just noise in this case. It's never bubbled
> > to the top of my list to fix...
> > 
> > > I'm going to take a look at it, but let me know if anybody has already
> > > found/fixed it.
> > 
> > If it is failing the check_scratch_fs stage, then it is most likely
> > the above issue. The corrupted btree problem that the test was
> > writen for caused the system to ASSERT fail or crash - i.e. it
> > didn't even run to the point of checking the fs....
> > 
> Yep, that was my point, it's failing on check_scratch_fs stage. The btree
> problem has been fixed since it is not triggering the ASSERT. Didn't know it is
> failing since its creation :)
> 
> I can add it to my todo list if you want some stuff out of yours

You can - the simplest thing to do might be just to fix the log size
for the mkfs command to 15MB (i.e. smaller than the AG size) so that
mkfs doesn't use all the space in the AG...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: xfstests 250 fail on newer kernels
  2012-10-21 22:31     ` Dave Chinner
@ 2012-10-23 12:24       ` Christoph Hellwig
  0 siblings, 0 replies; 5+ messages in thread
From: Christoph Hellwig @ 2012-10-23 12:24 UTC (permalink / raw)
  To: Dave Chinner; +Cc: xfs

On Mon, Oct 22, 2012 at 09:31:58AM +1100, Dave Chinner wrote:
> You can - the simplest thing to do might be just to fix the log size
> for the mkfs command to 15MB (i.e. smaller than the AG size) so that
> mkfs doesn't use all the space in the AG...

I'd love to still have another test for the mkfs issue, though.

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2012-10-23 12:22 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-19 17:37 xfstests 250 fail on newer kernels Carlos Maiolino
2012-10-19 21:53 ` Dave Chinner
2012-10-20 11:24   ` Carlos Maiolino
2012-10-21 22:31     ` Dave Chinner
2012-10-23 12:24       ` Christoph Hellwig

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.