XFS_WANT_CORRUPTED_GOTO at line 4528 of file fs/xfs/xfs_bmap.c

XFS_WANT_CORRUPTED_GOTO at line 4528 of file fs/xfs/xfs_bmap.c

[Carl-Johan Kjellander]

I've been hit by a bug installing FC6test4. It will hold us back upgrading
since we use XFS for our home-dirs at work.

Here is the link to the bug report at redhat's bugzilla:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211086

Here is dmesg when I try to read the file /var/lib/rpm/Packages:

XFS internal error XFS_WANT_CORRUPTED_GOTO at line 4528 of file
fs/xfs/xfs_bmap.c.  Caller 0xeeb4e6ba
  [<c040571a>] dump_trace+0x69/0x1af
  [<c0405878>] show_trace_log_lvl+0x18/0x2c
  [<c0405e18>] show_trace+0xf/0x11
  [<c0405e47>] dump_stack+0x15/0x17
  [<eeb3128a>] xfs_bmap_read_extents+0x448/0x462 [xfs]
  [<eeb4e6ba>] xfs_iread_extents+0xa0/0xbb [xfs]
  [<eeb2e692>] xfs_bmapi+0x23a/0x1f83 [xfs]
  [<eeb50e1d>] xfs_iomap+0x2e1/0x78d [xfs]
  [<eeb6c52e>] __xfs_get_blocks+0x72/0x237 [xfs]
  [<eeb6c748>] xfs_get_blocks+0x28/0x2d [xfs]
  [<c0484fa9>] do_mpage_readpage+0x282/0x5e2
  [<c048581c>] mpage_readpages+0xac/0x114
  [<c044d03f>] __do_page_cache_readahead+0x124/0x1c8
  [<c044d12f>] blockable_page_cache_readahead+0x4c/0x9f
  [<c044d2da>] page_cache_readahead+0xbf/0x196
  [<c044793b>] do_generic_mapping_read+0x13d/0x49b
  [<c0448573>] __generic_file_aio_read+0x18c/0x1d1
  [<eeb73b3c>] xfs_read+0x294/0x2fc [xfs]
  [<eeb707b7>] xfs_file_aio_read+0x70/0x78 [xfs]
  [<c0465c3a>] do_sync_read+0xc1/0xfb
  [<c04665bc>] vfs_read+0xa6/0x157
  [<c0466a2b>] sys_read+0x41/0x67
  [<c0404ea7>] syscall_call+0x7/0xb
DWARF2 unwinder stuck at syscall_call+0x7/0xb

I have the actual partition bzip:ed.
http://razor.csbnet.se/varfucked.bz2

Unpack it and dd to a 4GB logical volume and try to read from
/var/lib/rpm/Packages

/cjk
-- 
begin 644 carljohan_at_kjellander_dot_com.gif
Y1TE&.#=A(0`F`(```````/___RP`````(0`F```"@XR/!\N<#U.;+MI`<[U(>\!UGQ9BGT%>'D2I
Y*=NX,2@OUF2&<827ILW;^822C>\7!!Z1,!K'B5(6H<SH-"E*TJ3%*/>QI6:7"A>Y?):D2^*U@NCV
R<MOQ=]V(B6>LZYD-_T1U<@3W]A4(^$-W4]A#V")W6#.R"$;IR'@).46BN7$9>5D``#L`

RE: XFS_WANT_CORRUPTED_GOTO at line 4528 of file fs/xfs/xfs_bmap.c

[Shailendra Tripathi]

Hi Carl,
           The best way to see what is going on is to see what log thinks it has. You must have got a message indicating the inode number and other details of the extent as indicated by the source.
 
         if(!rt && !gotp->br_startblock && (*lastxp != NULLEXTNUM <http://fxr.watson.org/fxr/ident?v=linux-2.6.11.8;i=NULLEXTNUM> )) {
               cmn_err <http://fxr.watson.org/fxr/ident?v=linux-2.6.11.8;i=cmn_err> (CE_PANIC <http://fxr.watson.org/fxr/ident?v=linux-2.6.11.8;i=CE_PANIC> ,"Access to block zero: fs: <%s> inode: %lld "
                        "start_block : %llx start_off : %llx blkcnt : %llx "
                       "extent-state : %x \n",
                        (ip <http://fxr.watson.org/fxr/ident?v=linux-2.6.11.8;i=ip> ->i_mount)->m_fsname,(long long)ip <http://fxr.watson.org/fxr/ident?v=linux-2.6.11.8;i=ip> ->i_ino,
                         gotp->br_startblock, gotp->br_startoff,
                         gotp->br_blockcount,gotp->br_state);
        }

 
 
Can you attach the hex dump of complete log with inode and extent information ? I want to see what has gone into the log for the operations on this inode. It could be that the extent map was corrupted just before shutdown or something in recovery screwed up. 
-shailendra
 
From: xfs-bounce@oss.sgi.com on behalf of Carl-Johan Kjellander
Sent: Fri 10/20/2006 6:34 PM
To: xfs@oss.sgi.com
Subject: XFS_WANT_CORRUPTED_GOTO at line 4528 of file fs/xfs/xfs_bmap.c



I've been hit by a bug installing FC6test4. It will hold us back upgrading
since we use XFS for our home-dirs at work.

Here is the link to the bug report at redhat's bugzilla:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211086

Here is dmesg when I try to read the file /var/lib/rpm/Packages:

XFS internal error XFS_WANT_CORRUPTED_GOTO at line 4528 of file
fs/xfs/xfs_bmap.c.  Caller 0xeeb4e6ba
  [<c040571a>] dump_trace+0x69/0x1af
  [<c0405878>] show_trace_log_lvl+0x18/0x2c
  [<c0405e18>] show_trace+0xf/0x11
  [<c0405e47>] dump_stack+0x15/0x17
  [<eeb3128a>] xfs_bmap_read_extents+0x448/0x462 [xfs]
  [<eeb4e6ba>] xfs_iread_extents+0xa0/0xbb [xfs]
  [<eeb2e692>] xfs_bmapi+0x23a/0x1f83 [xfs]
  [<eeb50e1d>] xfs_iomap+0x2e1/0x78d [xfs]
  [<eeb6c52e>] __xfs_get_blocks+0x72/0x237 [xfs]
  [<eeb6c748>] xfs_get_blocks+0x28/0x2d [xfs]
  [<c0484fa9>] do_mpage_readpage+0x282/0x5e2
  [<c048581c>] mpage_readpages+0xac/0x114
  [<c044d03f>] __do_page_cache_readahead+0x124/0x1c8
  [<c044d12f>] blockable_page_cache_readahead+0x4c/0x9f
  [<c044d2da>] page_cache_readahead+0xbf/0x196
  [<c044793b>] do_generic_mapping_read+0x13d/0x49b
  [<c0448573>] __generic_file_aio_read+0x18c/0x1d1
  [<eeb73b3c>] xfs_read+0x294/0x2fc [xfs]
  [<eeb707b7>] xfs_file_aio_read+0x70/0x78 [xfs]
  [<c0465c3a>] do_sync_read+0xc1/0xfb
  [<c04665bc>] vfs_read+0xa6/0x157
  [<c0466a2b>] sys_read+0x41/0x67
  [<c0404ea7>] syscall_call+0x7/0xb
DWARF2 unwinder stuck at syscall_call+0x7/0xb

I have the actual partition bzip:ed.
http://razor.csbnet.se/varfucked.bz2

Unpack it and dd to a 4GB logical volume and try to read from
/var/lib/rpm/Packages

/cjk
--
begin 644 carljohan_at_kjellander_dot_com.gif
Y1TE&.#=A(0`F`(```````/___RP`````(0`F```"@XR/!\N<#U.;+MI`<[U(>\!UGQ9BGT%>'D2I
Y*=NX,2@OUF2&<827ILW;^822C>\7!!Z1,!K'B5(6H<SH-"E*TJ3%*/>QI6:7"A>Y?):D2^*U@NCV
R<MOQ=]V(B6>LZYD-_T1U<@3W]A4(^$-W4]A#V")W6#.R"$;IR'@).46BN7$9>5D``#L`






[[HTML alternate version deleted]]

Re: XFS_WANT_CORRUPTED_GOTO at line 4528 of file fs/xfs/xfs_bmap.c

[Eric Sandeen]

Shailendra Tripathi wrote:
> Hi Carl,
>            The best way to see what is going on is to see what log thinks it has. You must have got a message indicating the inode number and other details of the extent as indicated by the source.
>  
>          if(!rt && !gotp->br_startblock && (*lastxp != NULLEXTNUM <http://fxr.watson.org/fxr/ident?v=linux-2.6.11.8;i=NULLEXTNUM> )) {
>                cmn_err <http://fxr.watson.org/fxr/ident?v=linux-2.6.11.8;i=cmn_err> (CE_PANIC <http://fxr.watson.org/fxr/ident?v=linux-2.6.11.8;i=CE_PANIC> ,"Access to block zero: fs: <%s> inode: %lld "
>                         "start_block : %llx start_off : %llx blkcnt : %llx "
>                        "extent-state : %x \n",
>                         (ip <http://fxr.watson.org/fxr/ident?v=linux-2.6.11.8;i=ip> ->i_mount)->m_fsname,(long long)ip <http://fxr.watson.org/fxr/ident?v=linux-2.6.11.8;i=ip> ->i_ino,
>                          gotp->br_startblock, gotp->br_startoff,
>                          gotp->br_blockcount,gotp->br_state);
>         }
> 
>  
>  
> Can you attach the hex dump of complete log with inode and extent information ? I want to see what has gone into the log for the operations on this inode. It could be that the extent map was corrupted just before shutdown or something in recovery screwed up. 
> -shailendra

(russell, looks like your take-message-rewriter is going a bit nuts up there? or 
something)

Anyway, the code in question that tripped here is:

                 XFS_WANT_CORRUPTED_GOTO(
                         XFS_BMAP_SANITY_CHECK(mp, block, level),
                         error0);

which is checking magic & other things.

The filesystem is corrupted; I'd guess this may be from 4kstacks + xfs + lvm + raid.

the image he provided has a clean log...
XFS mounting filesystem loop0
Ending clean XFS mount for filesystem: loop0

this file is one of the ones in bad shape as he mentioned:

[root@link-07 tmp]# ls -i mnt/lib/rpm/Packages
1048708 mnt/lib/rpm/Packages

in my case if I try to read it I get:

attempt to access beyond end of device
loop0: rw=0, want=1546188226568, limit=4194304
I/O error in filesystem ("loop0") meta-data dev loop0 block 0x16800000000 
("xfs_trans_read_buf") error 5 buf count 4096
attempt to access beyond end of device

the inode looks like :

xfs_db> p
core.magic = 0x494e
core.mode = 0100644
core.version = 1
core.format = 3 (btree)
core.nlinkv1 = 1
core.uid = 37
core.gid = 37
core.flushiter = 121
core.atime.sec = Sun Oct 15 17:17:38 2006
core.atime.nsec = 403299952
core.mtime.sec = Sun Oct 15 17:17:38 2006
core.mtime.nsec = 403299952
core.ctime.sec = Sun Oct 15 17:17:45 2006
core.ctime.nsec = 983773702
core.size = 21340160
core.nblocks = 5212
core.extsize = 0
core.nextents = 154
core.naextents = 1
core.forkoff = 15
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.immutable = 0
core.append = 0
core.sync = 0
core.noatime = 0
core.nodump = 0
core.rtinherit = 0
core.projinherit = 0
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 0
core.gen = 0
next_unlinked = null
u.bmbt.level = 1
u.bmbt.numrecs = 1
u.bmbt.keys[1] = [startoff] 1:[0]
u.bmbt.ptrs[1] = 1:1233986491173044224
a.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,72071,1,0]

repair output:

repair output follows.

[root@link-07 tmp]# xfs_repair -n image
Phase 1 - find and verify superblock...
Phase 2 - using internal log
         - scan filesystem freespace and inode maps...
would zero unused portion of primary superblock (AG #0)
would zero unused portion of secondary superblock (AG #1)
would zero unused portion of secondary superblock (AG #2)
would zero unused portion of secondary superblock (AG #3)
would zero unused portion of secondary superblock (AG #4)
would zero unused portion of secondary superblock (AG #5)
would zero unused portion of secondary superblock (AG #6)
would zero unused portion of secondary superblock (AG #7)
         - found root inode chunk
Phase 3 - for each AG...
         - scan (but don't clear) agi unlinked lists...
         - process known inodes and perform inode discovery...
         - agno = 0
         - agno = 1
bad bmap btree ptr 0x1120002d00000000 in ino 1048708
bad data fork in inode 1048708
would have cleared inode 1048708
bad bmap btree ptr 0x8000000300000000 in ino 1048709
bad data fork in inode 1048709
would have cleared inode 1048709
bad bmap btree ptr 0x57e0001700000000 in ino 1048711
bad data fork in inode 1048711
would have cleared inode 1048711
bad bmap btree ptr 0x9b00000200000000 in ino 1048716
bad data fork in inode 1048716
would have cleared inode 1048716
bad bmap btree ptr 0x9140000100000000 in ino 1048717
bad data fork in inode 1048717
would have cleared inode 1048717
bad bmap btree ptr 0xbf00000100000000 in ino 1048718
bad data fork in inode 1048718
would have cleared inode 1048718
bad bmap btree ptr 0xa840000100000000 in ino 1048719
bad data fork in inode 1048719
would have cleared inode 1048719
bad bmap btree ptr 0x6b00000100000000 in ino 1048722
bad data fork in inode 1048722
would have cleared inode 1048722
bad bmap btree ptr 0x98c0000100000000 in ino 1048723
bad data fork in inode 1048723
would have cleared inode 1048723
         - agno = 2
         - agno = 3
         - agno = 4
         - agno = 5
         - agno = 6
         - agno = 7
         - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
         - setting up duplicate extent list...
         - check for inodes claiming duplicate blocks...
         - agno = 0
         - agno = 1
entry "Packages" at block 0 offset 144 in directory inode 1048704 references 
free inode 1048708
         would clear inode number in entry at offset 144...
entry "Providename" at block 0 offset 200 in directory inode 1048704 references 
free inode 1048709
         would clear inode number in entry at offset 200...
entry "Basenames" at block 0 offset 312 in directory inode 1048704 references 
free inode 1048711
         would clear inode number in entry at offset 312...
entry "Requirename" at block 0 offset 520 in directory inode 1048704 references 
free inode 1048716
         would clear inode number in entry at offset 520...
entry "Dirnames" at block 0 offset 568 in directory inode 1048704 references 
free inode 1048717
         would clear inode number in entry at offset 568...
entry "Requireversion" at block 0 offset 624 in directory inode 1048704 
references free inode 1048718
         would clear inode number in entry at offset 624...
entry "Provideversion" at block 0 offset 688 in directory inode 1048704 
references free inode 1048719
         would clear inode number in entry at offset 688...
entry "Sha1header" at block 0 offset 856 in directory inode 1048704 references 
free inode 1048722
         would clear inode number in entry at offset 856...
entry "Filemd5s" at block 0 offset 904 in directory inode 1048704 references 
free inode 1048723
         would clear inode number in entry at offset 904...
bad bmap btree ptr 0x1120002d00000000 in ino 1048708
bad data fork in inode 1048708
would have cleared inode 1048708
bad bmap btree ptr 0x8000000300000000 in ino 1048709
bad data fork in inode 1048709
would have cleared inode 1048709
bad bmap btree ptr 0x57e0001700000000 in ino 1048711
bad data fork in inode 1048711
would have cleared inode 1048711
bad bmap btree ptr 0x9b00000200000000 in ino 1048716
bad data fork in inode 1048716
would have cleared inode 1048716
bad bmap btree ptr 0x9140000100000000 in ino 1048717
bad data fork in inode 1048717
would have cleared inode 1048717
bad bmap btree ptr 0xbf00000100000000 in ino 1048718
bad data fork in inode 1048718
would have cleared inode 1048718
bad bmap btree ptr 0xa840000100000000 in ino 1048719
bad data fork in inode 1048719
would have cleared inode 1048719
bad bmap btree ptr 0x6b00000100000000 in ino 1048722
bad data fork in inode 1048722
would have cleared inode 1048722
bad bmap btree ptr 0x98c0000100000000 in ino 1048723
bad data fork in inode 1048723
would have cleared inode 1048723
         - agno = 2
         - agno = 3
         - agno = 4
         - agno = 5
         - agno = 6
         - agno = 7
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
         - traversing filesystem starting at / ...
entry "Packages" in directory inode 1048704 points to free inode 1048708, would 
junk entry
entry "Providename" in directory inode 1048704 points to free inode 1048709, 
would junk entry
entry "Basenames" in directory inode 1048704 points to free inode 1048711, would 
junk entry
entry "Requirename" in directory inode 1048704 points to free inode 1048716, 
would junk entry
entry "Dirnames" in directory inode 1048704 points to free inode 1048717, would 
junk entry
entry "Requireversion" in directory inode 1048704 points to free inode 1048718, 
would junk entry
entry "Provideversion" in directory inode 1048704 points to free inode 1048719, 
would junk entry
entry "Sha1header" in directory inode 1048704 points to free inode 1048722, 
would junk entry
entry "Filemd5s" in directory inode 1048704 points to free inode 1048723, would 
junk entry
         - traversal finished ...
         - traversing all unattached subtrees ...
         - traversals finished ...
         - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

Re: XFS_WANT_CORRUPTED_GOTO at line 4528 of file fs/xfs/xfs_bmap.c

[Shailendra Tripathi]

Eric Sandeen wrote:
> Anyway, the code in question that tripped here is:
>
>                 XFS_WANT_CORRUPTED_GOTO(
>                         XFS_BMAP_SANITY_CHECK(mp, block, level),
>                         error0);
>
> which is checking magic & other things.
>
OK. Thanks.
> The filesystem is corrupted; I'd guess this may be from 4kstacks + xfs 
> + lvm + raid.
>
Yes, the corruption is persisted. I'd like to think on another direction 
as well besides stack corruption isue and I have a reason for the same:

All the inodes which are corrupted are in the same region. The 
corruption starts from 1048704 which is a directory and other inodes 
which are corrupted are:

1048708
1048709
1048711
1048716
1048717
1048718
1048719
1048722
1048723

(gdb) p/x 1048704 % 64
$1 = 0x0
(gdb) p/x 1048708 % 64
$2 = 0x4
(gdb) p 1048723  % 64
$7 = 19
(gdb) p 1048723 - 1048704
$8 = 19

XFS flushes inodes in 8K buffer at a time. If I assume 256 byte inode(I 
couldn't get enough data to verify. I didn't hard to find if this is the 
case as well), so all these inodes are part of one flush buffer(32 
inodes will be flushed in one buffer). So, it could be possible that an 
I/O to the buffer is  lost somewhere. That's why, whole bunch of inodes 
in the same region are corrupted.

> the image he provided has a clean log...
> XFS mounting filesystem loop0
> Ending clean XFS mount for filesystem: loop0
>
> this file is one of the ones in bad shape as he mentioned:
>
> [root@link-07 tmp]# ls -i mnt/lib/rpm/Packages
> 1048708 mnt/lib/rpm/Packages
>
> in my case if I try to read it I get:
>
> attempt to access beyond end of device
> loop0: rw=0, want=1546188226568, limit=4194304
> I/O error in filesystem ("loop0") meta-data dev loop0 block 
> 0x16800000000 ("xfs_trans_read_buf") error 5 buf count 4096
> attempt to access beyond end of device
>
> the inode looks like :
>
> xfs_db> p
> core.magic = 0x494e
> core.mode = 0100644
> core.version = 1
> core.format = 3 (btree)
> core.nlinkv1 = 1
> core.uid = 37
> core.gid = 37
> core.flushiter = 121
> core.atime.sec = Sun Oct 15 17:17:38 2006
> core.atime.nsec = 403299952
> core.mtime.sec = Sun Oct 15 17:17:38 2006
> core.mtime.nsec = 403299952
> core.ctime.sec = Sun Oct 15 17:17:45 2006
> core.ctime.nsec = 983773702
> core.size = 21340160
> core.nblocks = 5212
> core.extsize = 0
> core.nextents = 154
> core.naextents = 1
> core.forkoff = 15
> core.aformat = 2 (extents)
> core.dmevmask = 0
> core.dmstate = 0
> core.newrtbm = 0
> core.prealloc = 0
> core.realtime = 0
> core.immutable = 0
> core.append = 0
> core.sync = 0
> core.noatime = 0
> core.nodump = 0
> core.rtinherit = 0
> core.projinherit = 0
> core.nosymlinks = 0
> core.extsz = 0
> core.extszinherit = 0
> core.nodefrag = 0
> core.gen = 0
> next_unlinked = null
> u.bmbt.level = 1
> u.bmbt.numrecs = 1
> u.bmbt.keys[1] = [startoff] 1:[0]
> u.bmbt.ptrs[1] = 1:1233986491173044224
> a.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,72071,1,0]
>
> repair output:
>
> repair output follows.
>
> [root@link-07 tmp]# xfs_repair -n image
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
>         - scan filesystem freespace and inode maps...
> would zero unused portion of primary superblock (AG #0)
> would zero unused portion of secondary superblock (AG #1)
> would zero unused portion of secondary superblock (AG #2)
> would zero unused portion of secondary superblock (AG #3)
> would zero unused portion of secondary superblock (AG #4)
> would zero unused portion of secondary superblock (AG #5)
> would zero unused portion of secondary superblock (AG #6)
> would zero unused portion of secondary superblock (AG #7)
>         - found root inode chunk
> Phase 3 - for each AG...
>         - scan (but don't clear) agi unlinked lists...
>         - process known inodes and perform inode discovery...
>         - agno = 0
>         - agno = 1
> bad bmap btree ptr 0x1120002d00000000 in ino 1048708
> bad data fork in inode 1048708
> would have cleared inode 1048708
> bad bmap btree ptr 0x8000000300000000 in ino 1048709
> bad data fork in inode 1048709
> would have cleared inode 1048709
> bad bmap btree ptr 0x57e0001700000000 in ino 1048711
> bad data fork in inode 1048711
> would have cleared inode 1048711
> bad bmap btree ptr 0x9b00000200000000 in ino 1048716
> bad data fork in inode 1048716
> would have cleared inode 1048716
> bad bmap btree ptr 0x9140000100000000 in ino 1048717
> bad data fork in inode 1048717
> would have cleared inode 1048717
> bad bmap btree ptr 0xbf00000100000000 in ino 1048718
> bad data fork in inode 1048718
> would have cleared inode 1048718
> bad bmap btree ptr 0xa840000100000000 in ino 1048719
> bad data fork in inode 1048719
> would have cleared inode 1048719
> bad bmap btree ptr 0x6b00000100000000 in ino 1048722
> bad data fork in inode 1048722
> would have cleared inode 1048722
> bad bmap btree ptr 0x98c0000100000000 in ino 1048723
> bad data fork in inode 1048723
> would have cleared inode 1048723
>         - agno = 2
>         - agno = 3
>         - agno = 4
>         - agno = 5
>         - agno = 6
>         - agno = 7
>         - process newly discovered inodes...
> Phase 4 - check for duplicate blocks...
>         - setting up duplicate extent list...
>         - check for inodes claiming duplicate blocks...
>         - agno = 0
>         - agno = 1
> entry "Packages" at block 0 offset 144 in directory inode 1048704 
> references free inode 1048708
>         would clear inode number in entry at offset 144...
> entry "Providename" at block 0 offset 200 in directory inode 1048704 
> references free inode 1048709
>         would clear inode number in entry at offset 200...
> entry "Basenames" at block 0 offset 312 in directory inode 1048704 
> references free inode 1048711
>         would clear inode number in entry at offset 312...
> entry "Requirename" at block 0 offset 520 in directory inode 1048704 
> references free inode 1048716
>         would clear inode number in entry at offset 520...
> entry "Dirnames" at block 0 offset 568 in directory inode 1048704 
> references free inode 1048717
>         would clear inode number in entry at offset 568...
> entry "Requireversion" at block 0 offset 624 in directory inode 
> 1048704 references free inode 1048718
>         would clear inode number in entry at offset 624...
> entry "Provideversion" at block 0 offset 688 in directory inode 
> 1048704 references free inode 1048719
>         would clear inode number in entry at offset 688...
> entry "Sha1header" at block 0 offset 856 in directory inode 1048704 
> references free inode 1048722
>         would clear inode number in entry at offset 856...
> entry "Filemd5s" at block 0 offset 904 in directory inode 1048704 
> references free inode 1048723
>         would clear inode number in entry at offset 904...
> bad bmap btree ptr 0x1120002d00000000 in ino 1048708
> bad data fork in inode 1048708
> would have cleared inode 1048708
> bad bmap btree ptr 0x8000000300000000 in ino 1048709
> bad data fork in inode 1048709
> would have cleared inode 1048709
> bad bmap btree ptr 0x57e0001700000000 in ino 1048711
> bad data fork in inode 1048711
> would have cleared inode 1048711
> bad bmap btree ptr 0x9b00000200000000 in ino 1048716
> bad data fork in inode 1048716
> would have cleared inode 1048716
> bad bmap btree ptr 0x9140000100000000 in ino 1048717
> bad data fork in inode 1048717
> would have cleared inode 1048717
> bad bmap btree ptr 0xbf00000100000000 in ino 1048718
> bad data fork in inode 1048718
> would have cleared inode 1048718
> bad bmap btree ptr 0xa840000100000000 in ino 1048719
> bad data fork in inode 1048719
> would have cleared inode 1048719
> bad bmap btree ptr 0x6b00000100000000 in ino 1048722
> bad data fork in inode 1048722
> would have cleared inode 1048722
> bad bmap btree ptr 0x98c0000100000000 in ino 1048723
> bad data fork in inode 1048723
> would have cleared inode 1048723
>         - agno = 2
>         - agno = 3
>         - agno = 4
>         - agno = 5
>         - agno = 6
>         - agno = 7
> No modify flag set, skipping phase 5
> Phase 6 - check inode connectivity...
>         - traversing filesystem starting at / ...
> entry "Packages" in directory inode 1048704 points to free inode 
> 1048708, would junk entry
> entry "Providename" in directory inode 1048704 points to free inode 
> 1048709, would junk entry
> entry "Basenames" in directory inode 1048704 points to free inode 
> 1048711, would junk entry
> entry "Requirename" in directory inode 1048704 points to free inode 
> 1048716, would junk entry
> entry "Dirnames" in directory inode 1048704 points to free inode 
> 1048717, would junk entry
> entry "Requireversion" in directory inode 1048704 points to free inode 
> 1048718, would junk entry
> entry "Provideversion" in directory inode 1048704 points to free inode 
> 1048719, would junk entry
> entry "Sha1header" in directory inode 1048704 points to free inode 
> 1048722, would junk entry
> entry "Filemd5s" in directory inode 1048704 points to free inode 
> 1048723, would junk entry
>         - traversal finished ...
>         - traversing all unattached subtrees ...
>         - traversals finished ...
>         - moving disconnected inodes to lost+found ...
> Phase 7 - verify link counts...
> No modify flag set, skipping filesystem flush and exiting.