Updated xfsprogs 2.6.38 merge
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.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Dave Chinner
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-devkernel-2.6.38-sync
Quoted 7 lines
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:
include/Makefile +1 -1
@@ -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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 27 lines · Christoph Hellwig
Quoted 10 lines · Dave Chinner
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-devkernel-2.6.38-syncQuoted 7 lines
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.hremoval I pointed out last round:Index: xfsprogs-dev/include/Makefile
===================================================================
include/Makefile QAHFILES = libxfs.h libxlog.h \ · line 33
Quoted 8 lines
include/Makefile +1
-1@@ -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.
Quoted 11 lines
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.
0x0805736bintag_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.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 12 lines · Dave Chinner
Quoted 11 lines
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.
0x0805736bintag_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
Quoted 1 line
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Dave Chinner
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-devkernel-2.6.38-sync
Quoted 7 lines
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 14 lines · Dave Chinner
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-devkernel-2.6.38-syncIt'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.
Quoted 7 lines
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...
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs