* xfsprogs 3.1.0 repair problems?
@ 2010-01-15 3:08 Eric Sandeen
2010-01-15 3:52 ` Dave Chinner
2010-01-15 5:56 ` Dave Chinner
0 siblings, 2 replies; 5+ messages in thread
From: Eric Sandeen @ 2010-01-15 3:08 UTC (permalink / raw)
To: xfs-oss
It looks like maybe the freespace checking isn't quite up to par:
test 073 is dying with:
_check_xfs_filesystem: filesystem on /mnt/test/14309.image is inconsistent
*** xfs_repair -n output ***
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- scan filesystem freespace and inode maps...
sb_fdblocks 26156829, counted 26157853
- found root inode chunk
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: xfsprogs 3.1.0 repair problems? 2010-01-15 3:08 xfsprogs 3.1.0 repair problems? Eric Sandeen @ 2010-01-15 3:52 ` Dave Chinner 2010-01-15 4:15 ` Eric Sandeen 2010-01-15 5:56 ` Dave Chinner 1 sibling, 1 reply; 5+ messages in thread From: Dave Chinner @ 2010-01-15 3:52 UTC (permalink / raw) To: Eric Sandeen; +Cc: xfs-oss On Thu, Jan 14, 2010 at 09:08:46PM -0600, Eric Sandeen wrote: > It looks like maybe the freespace checking isn't quite up to par: > > test 073 is dying with: > > _check_xfs_filesystem: filesystem on /mnt/test/14309.image is inconsistent > *** xfs_repair -n output *** > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - scan filesystem freespace and inode maps... > sb_fdblocks 26156829, counted 26157853 Actually, that looks like it is out by exactly 1024 blocks, which is the default amount of reserved space in the filesystem. Perhaps there is something else wrong with the unmount code that is not unreserving this space before the superblock is written to disk? I'm about to see if I can reproduce it.... 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: xfsprogs 3.1.0 repair problems? 2010-01-15 3:52 ` Dave Chinner @ 2010-01-15 4:15 ` Eric Sandeen 0 siblings, 0 replies; 5+ messages in thread From: Eric Sandeen @ 2010-01-15 4:15 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs-oss Dave Chinner wrote: > On Thu, Jan 14, 2010 at 09:08:46PM -0600, Eric Sandeen wrote: >> It looks like maybe the freespace checking isn't quite up to par: >> >> test 073 is dying with: >> >> _check_xfs_filesystem: filesystem on /mnt/test/14309.image is inconsistent >> *** xfs_repair -n output *** >> Phase 1 - find and verify superblock... >> Phase 2 - using internal log >> - scan filesystem freespace and inode maps... >> sb_fdblocks 26156829, counted 26157853 > > Actually, that looks like it is out by exactly 1024 blocks, which is > the default amount of reserved space in the filesystem. Perhaps > there is something else wrong with the unmount code that > is not unreserving this space before the superblock is > written to disk? > > I'm about to see if I can reproduce it.... > > Cheers, > > Dave. Thanks, you may need some of the patches I sent to the list today to make mkfs happy first :) -Eric _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: xfsprogs 3.1.0 repair problems? 2010-01-15 3:08 xfsprogs 3.1.0 repair problems? Eric Sandeen 2010-01-15 3:52 ` Dave Chinner @ 2010-01-15 5:56 ` Dave Chinner 2010-01-15 20:47 ` Eric Sandeen 1 sibling, 1 reply; 5+ messages in thread From: Dave Chinner @ 2010-01-15 5:56 UTC (permalink / raw) To: Eric Sandeen; +Cc: xfs-oss On Thu, Jan 14, 2010 at 09:08:46PM -0600, Eric Sandeen wrote: > It looks like maybe the freespace checking isn't quite up to par: > > test 073 is dying with: > > _check_xfs_filesystem: filesystem on /mnt/test/14309.image is inconsistent > *** xfs_repair -n output *** > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - scan filesystem freespace and inode maps... > sb_fdblocks 26156829, counted 26157853 > - found root inode chunk This is caused by the remount,ro done in the test - the superblock is written to disk with the reserved blocks considered used. At unmount time those reserve blocks are "freed" before the superblock is written and so the total is correct at that time. I'm going to go look at the kernel code now... 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: xfsprogs 3.1.0 repair problems? 2010-01-15 5:56 ` Dave Chinner @ 2010-01-15 20:47 ` Eric Sandeen 0 siblings, 0 replies; 5+ messages in thread From: Eric Sandeen @ 2010-01-15 20:47 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs-oss Dave Chinner wrote: > On Thu, Jan 14, 2010 at 09:08:46PM -0600, Eric Sandeen wrote: >> It looks like maybe the freespace checking isn't quite up to par: >> >> test 073 is dying with: >> >> _check_xfs_filesystem: filesystem on /mnt/test/14309.image is inconsistent >> *** xfs_repair -n output *** >> Phase 1 - find and verify superblock... >> Phase 2 - using internal log >> - scan filesystem freespace and inode maps... >> sb_fdblocks 26156829, counted 26157853 >> - found root inode chunk > > This is caused by the remount,ro done in the test - the superblock > is written to disk with the reserved blocks considered used. At > unmount time those reserve blocks are "freed" before the superblock > is written and so the total is correct at that time. > > I'm going to go look at the kernel code now... > > Cheers, > > Dave. Today, I'm intermittently getting xfs_repair segfaults, in btree_get_prev, but this seems odd: Program terminated with signal 11, Segmentation fault. #0 btree_get_prev (key=0x9fc330, root=0x9fc300) at btree.c:190 p190 if (cur->index > 0) { (gdb) list btree.c:190 185 { 186 struct btree_cursor *cur = root->cursor; 187 int level = 0; 188 struct btree_node *node; 189 190 if (cur->index > 0) { 191 if (key) 192 *key = cur->node->keys[cur->index - 1]; 193 return cur->node->ptrs[cur->index - 1]; 194 } (gdb) p *root $1 = {root_node = 0x7fca8400fac0, cursor = 0x7fca8400e0e0, height = 1, keys_valid = 1, cur_key = 6792640, next_key = 0, next_value = 0x0, prev_key = 0, prev_value = 0x0} (gdb) p cur $2 = (struct btree_cursor *) 0x0 (gdb) quit root->cursor is valid, but cur is not? Still looking.... But maybe related to the initial problem... this is cropping up in the post-test check & repair that xfstests does. I imaged the filesystem before the checking in hopes of getting a reproducer. When the testsuite runs, repair looks clean, but then it segfaults. If I then point repair at the filesystem image I created prior to the segfault, it lights up with tons of errors. I'm confused by that; one interesting thing is that repair is testing a mounted, readonly filesystem when xfstests runs. -Eric _______________________________________________ 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:[~2010-01-15 20:47 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-01-15 3:08 xfsprogs 3.1.0 repair problems? Eric Sandeen 2010-01-15 3:52 ` Dave Chinner 2010-01-15 4:15 ` Eric Sandeen 2010-01-15 5:56 ` Dave Chinner 2010-01-15 20:47 ` Eric Sandeen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox