xfs
[Top] [All Lists]

Re: more xfs on ppc

To: Thomas Graichen <graichen@xxxxxxxxxxxxx>, thomas.graichen@xxxxxxxxxxxxx
Subject: Re: more xfs on ppc
From: Steve Lord <lord@xxxxxxx>
Date: Mon, 28 Aug 2000 11:40:20 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: Message from Thomas Graichen <news-innominate.list.sgi.xfs@xxxxxxxxxxxxx> of "27 Aug 2000 09:49:03 GMT." <news2mail-8oao6f$bvk$1@xxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
I took a quick look at the filesystem image, and the second file (test) is
there:

 xfs_db -f xfs-ppc-bug.dd
xfs_db: inode 128
xfs_db: print
core.magic = 0x494e
core.mode = 040755
core.version = 1
core.format = 1 (local)
core.nlinkv1 = 2
core.uid = 0
core.gid = 0
core.atime.sec = Sun Aug 27 07:42:08 2000
core.atime.nsec = 360000000
core.mtime.sec = Sun Aug 27 07:42:04 2000
core.mtime.nsec = 440000000
core.ctime.sec = Sun Aug 27 07:42:04 2000
core.ctime.nsec = 440000000
core.size = 27
core.nblocks = 0
core.extsize = 0
core.nextents = 0
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.gen = 0
next_unlinked = null
u.sfdir2.hdr.count = 2
u.sfdir2.hdr.i8count = 0
u.sfdir2.hdr.parent.i4 = 128
u.sfdir2.list[0].namelen = 3
u.sfdir2.list[0].offset = 0x30
u.sfdir2.list[0].name = "XFS"
u.sfdir2.list[0].inumber.i4 = 131
u.sfdir2.list[1].namelen = 4
u.sfdir2.list[1].offset = 0x40
u.sfdir2.list[1].name = "test"
u.sfdir2.list[1].inumber.i4 = 0

However, the inode number is bad it should be 132, the cat command must
be using a dcache entry setup by the create call.

Repair seems to confirm this:

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
        - 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
entry "test" in shortform directory 128 references invalid inode 0
would have junked entry "test" in directory inode 128
        - agno = 1
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
entry "test" in shortform directory 128 references invalid inode 0
would have junked entry "test" in directory inode 128
        - agno = 1
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem starting at / ... 
        - traversal finished ... 
        - traversing all unattached subtrees ... 
        - traversals finished ... 
        - moving disconnected inodes to lost+found ... 
disconnected inode 132, would move to lost+found
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

So somehow the wrong inode number got pushed down to the disk. I will do some
more digging.

Steve





<Prev in Thread] Current Thread [Next in Thread>