* Re: Updated xfsprogs 2.6.38 merge
2011-07-05 2:48 Updated xfsprogs 2.6.38 merge Dave Chinner
@ 2011-07-10 21:01 ` Christoph Hellwig
2011-07-11 0:01 ` Dave Chinner
2011-07-22 15:57 ` Christoph Hellwig
2011-07-29 22:12 ` Alex Elder
2 siblings, 1 reply; 6+ messages in thread
From: Christoph Hellwig @ 2011-07-10 21:01 UTC (permalink / raw)
To: Dave Chinner; +Cc: xfs
On Tue, Jul 05, 2011 at 12:48:55PM +1000, Dave Chinner wrote:
> Folks,
>
> I pushed out an updated 2.6.38 kernel merge to xfsprogs patchset a
> couple of days ago. I've been doing quite a bit of testing on it,
> both 32 bit and 64 bit, with 512 byte, 1k and 4k block size
> filesystems and I haven't come across any regressions. The patchset
> can be found here:
>
> git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev kernel-2.6.38-sync
>
> It's pretty much unchanged from the last set of patches I sent,
> except for one minor fix to the radix tree code for an off by one in
> the path array size for item and tag deletes.
>
> I'm pretty much ready to commit this update so I can then move
> forward with updating it to the 3.0 kernel code base as a smaller
> incremental series.
It's still missing the fix for the xfs_imap.h removal I pointed out last
round:
Index: xfsprogs-dev/include/Makefile
===================================================================
--- xfsprogs-dev.orig/include/Makefile 2011-07-10 20:51:24.000000000 +0000
+++ xfsprogs-dev/include/Makefile 2011-07-10 20:51:31.000000000 +0000
@@ -27,7 +27,7 @@ QAHFILES = libxfs.h libxlog.h \
xfs_dir2.h xfs_dir2_block.h xfs_dir2_data.h xfs_dir2_leaf.h \
xfs_dir2_node.h xfs_dir2_sf.h xfs_dir_leaf.h xfs_dir_sf.h \
xfs_extfree_item.h xfs_ialloc.h xfs_ialloc_btree.h \
- xfs_imap.h xfs_inode.h xfs_inode_item.h xfs_inum.h \
+ xfs_inode.h xfs_inode_item.h xfs_inum.h \
xfs_log.h xfs_log_priv.h xfs_log_recover.h xfs_metadump.h \
xfs_mount.h xfs_quota.h xfs_rtalloc.h xfs_sb.h xfs_trace.h \
xfs_trans.h xfs_trans_space.h xfs_types.h xfs_dfrag.h
But even after that a simple mkfs crashed for me on 32-bit x86. Here is
the gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0805736b in tag_get (root=0xffffda5c, index=0) at radix-tree.c:82
82 return 1 & (((const __uint32_t *)node->tags[tag])[offset >> 5] >> (offset & 31));
(gdb) bt
#0 0x0805736b in tag_get (root=0xffffda5c, index=0) at radix-tree.c:82
#1 radix_tree_delete (root=0xffffda5c, index=0) at radix-tree.c:726
#2 0x08054ee7 in libxfs_umount (mp=0xffffd8f8) at init.c:822
#3 0x0805277c in main (argc=3, argv=0xffffdd94) at xfs_mkfs.c:2683
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Updated xfsprogs 2.6.38 merge
2011-07-10 21:01 ` Christoph Hellwig
@ 2011-07-11 0:01 ` Dave Chinner
2011-07-11 5:27 ` Christoph Hellwig
0 siblings, 1 reply; 6+ messages in thread
From: Dave Chinner @ 2011-07-11 0:01 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs
On Sun, Jul 10, 2011 at 05:01:13PM -0400, Christoph Hellwig wrote:
> On Tue, Jul 05, 2011 at 12:48:55PM +1000, Dave Chinner wrote:
> > Folks,
> >
> > I pushed out an updated 2.6.38 kernel merge to xfsprogs patchset a
> > couple of days ago. I've been doing quite a bit of testing on it,
> > both 32 bit and 64 bit, with 512 byte, 1k and 4k block size
> > filesystems and I haven't come across any regressions. The patchset
> > can be found here:
> >
> > git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev kernel-2.6.38-sync
> >
> > It's pretty much unchanged from the last set of patches I sent,
> > except for one minor fix to the radix tree code for an off by one in
> > the path array size for item and tag deletes.
> >
> > I'm pretty much ready to commit this update so I can then move
> > forward with updating it to the 3.0 kernel code base as a smaller
> > incremental series.
>
> It's still missing the fix for the xfs_imap.h removal I pointed out last
> round:
>
> Index: xfsprogs-dev/include/Makefile
> ===================================================================
> --- xfsprogs-dev.orig/include/Makefile 2011-07-10 20:51:24.000000000 +0000
> +++ xfsprogs-dev/include/Makefile 2011-07-10 20:51:31.000000000 +0000
> @@ -27,7 +27,7 @@ QAHFILES = libxfs.h libxlog.h \
> xfs_dir2.h xfs_dir2_block.h xfs_dir2_data.h xfs_dir2_leaf.h \
> xfs_dir2_node.h xfs_dir2_sf.h xfs_dir_leaf.h xfs_dir_sf.h \
> xfs_extfree_item.h xfs_ialloc.h xfs_ialloc_btree.h \
> - xfs_imap.h xfs_inode.h xfs_inode_item.h xfs_inum.h \
> + xfs_inode.h xfs_inode_item.h xfs_inum.h \
> xfs_log.h xfs_log_priv.h xfs_log_recover.h xfs_metadump.h \
> xfs_mount.h xfs_quota.h xfs_rtalloc.h xfs_sb.h xfs_trace.h \
> xfs_trans.h xfs_trans_space.h xfs_types.h xfs_dfrag.h
Strangely enough I don't see that failure. Fixed, anyway.
> But even after that a simple mkfs crashed for me on 32-bit x86. Here is
> the gdb backtrace:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0805736b in tag_get (root=0xffffda5c, index=0) at radix-tree.c:82
> 82 return 1 & (((const __uint32_t *)node->tags[tag])[offset >> 5] >> (offset & 31));
> (gdb) bt
> #0 0x0805736b in tag_get (root=0xffffda5c, index=0) at radix-tree.c:82
> #1 radix_tree_delete (root=0xffffda5c, index=0) at radix-tree.c:726
> #2 0x08054ee7 in libxfs_umount (mp=0xffffd8f8) at init.c:822
> #3 0x0805277c in main (argc=3, argv=0xffffdd94) at xfs_mkfs.c:2683
What size block device? It's not failing here...
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] 6+ messages in thread
* Re: Updated xfsprogs 2.6.38 merge
2011-07-11 0:01 ` Dave Chinner
@ 2011-07-11 5:27 ` Christoph Hellwig
0 siblings, 0 replies; 6+ messages in thread
From: Christoph Hellwig @ 2011-07-11 5:27 UTC (permalink / raw)
To: Dave Chinner; +Cc: Christoph Hellwig, xfs
On Mon, Jul 11, 2011 at 10:01:35AM +1000, Dave Chinner wrote:
> > But even after that a simple mkfs crashed for me on 32-bit x86. Here is
> > the gdb backtrace:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x0805736b in tag_get (root=0xffffda5c, index=0) at radix-tree.c:82
> > 82 return 1 & (((const __uint32_t *)node->tags[tag])[offset >> 5] >> (offset & 31));
> > (gdb) bt
> > #0 0x0805736b in tag_get (root=0xffffda5c, index=0) at radix-tree.c:82
> > #1 radix_tree_delete (root=0xffffda5c, index=0) at radix-tree.c:726
> > #2 0x08054ee7 in libxfs_umount (mp=0xffffd8f8) at init.c:822
> > #3 0x0805277c in main (argc=3, argv=0xffffdd94) at xfs_mkfs.c:2683
>
> What size block device? It's not failing here...
That was on a 40GB one, but I can also reproduce it on a 10GB one.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Updated xfsprogs 2.6.38 merge
2011-07-05 2:48 Updated xfsprogs 2.6.38 merge Dave Chinner
2011-07-10 21:01 ` Christoph Hellwig
@ 2011-07-22 15:57 ` Christoph Hellwig
2011-07-29 22:12 ` Alex Elder
2 siblings, 0 replies; 6+ messages in thread
From: Christoph Hellwig @ 2011-07-22 15:57 UTC (permalink / raw)
To: Dave Chinner; +Cc: xfs
On Tue, Jul 05, 2011 at 12:48:55PM +1000, Dave Chinner wrote:
> Folks,
>
> I pushed out an updated 2.6.38 kernel merge to xfsprogs patchset a
> couple of days ago. I've been doing quite a bit of testing on it,
> both 32 bit and 64 bit, with 512 byte, 1k and 4k block size
> filesystems and I haven't come across any regressions. The patchset
> can be found here:
>
> git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev kernel-2.6.38-sync
>
> It's pretty much unchanged from the last set of patches I sent,
> except for one minor fix to the radix tree code for an off by one in
> the path array size for item and tag deletes.
>
> I'm pretty much ready to commit this update so I can then move
> forward with updating it to the 3.0 kernel code base as a smaller
> incremental series.
With the xfs_imap.h changes in, and the radix-tree bits fixed up I'm
fine with this merge and you can add my reviewed-by tags to all commits.
I'd also suggest removing the testing details in the main patch commit
log, as it seems a bit misplaced in there.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Updated xfsprogs 2.6.38 merge
2011-07-05 2:48 Updated xfsprogs 2.6.38 merge Dave Chinner
2011-07-10 21:01 ` Christoph Hellwig
2011-07-22 15:57 ` Christoph Hellwig
@ 2011-07-29 22:12 ` Alex Elder
2 siblings, 0 replies; 6+ messages in thread
From: Alex Elder @ 2011-07-29 22:12 UTC (permalink / raw)
To: Dave Chinner; +Cc: xfs
On Tue, 2011-07-05 at 12:48 +1000, Dave Chinner wrote:
> Folks,
>
> I pushed out an updated 2.6.38 kernel merge to xfsprogs patchset a
> couple of days ago. I've been doing quite a bit of testing on it,
> both 32 bit and 64 bit, with 512 byte, 1k and 4k block size
> filesystems and I haven't come across any regressions. The patchset
> can be found here:
>
> git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev kernel-2.6.38-sync
>
> It's pretty much unchanged from the last set of patches I sent,
> except for one minor fix to the radix tree code for an off by one in
> the path array size for item and tag deletes.
>
> I'm pretty much ready to commit this update so I can then move
> forward with updating it to the 3.0 kernel code base as a smaller
> incremental series.
>
> Cheers,
>
> Dave.
I looked over the changes--the third one really since
the first two already indicated I'd signed off on them.
It is a very large patch, and most of the changes are
pretty easily seen to be straightforward transformations.
So my "review" consisted of a full-but-quick scan through
it.
More importantly, you report no regressions and I can
confirm that I haven't seen any myself either so far,
except that the golden output for test 122 needs to be
updated:
- to reflect that xfs_bmbt_rec_{32,64}_t have now
been replaced by xfs_bmbt_rec_t
- to reflect that xfs_dinode_core_t no longer exists
- and that xfs_alloctype_t isn't shown any more,
because it's no longer an enum type.
It looks to me like that test could be updated so it
looks for structure definitions rather than typedef's,
and possibly review the list of ignored types.
Anyway, I really want to see this committed so we can move
forward without further ado. So I say get it in...
Signed-off-by: Alex Elder <aelder@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread