[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jfs-discussion
Subject:    Re: [Jfs-discussion] Strange dir inode
From:       Dave Kleikamp <dave.kleikamp () oracle ! com>
Date:       2015-04-24 16:36:12
Message-ID: 553A70FC.4040707 () oracle ! com
[Download RAW message or body]

On 04/22/2015 06:09 AM, Felipe Monteiro de Carvalho wrote:
> Hello,
> 
> I've been working hard to get jfs read support in my software, and I
> try as hard as possible to figure out myself without asking question,
> but there is a very strange point where I got stuck =( Its a dir
> inode, which has 10.000 files inside it.
> 
> inode nr 12291 and offset 0x600460 presents us the following basic
> inode information:
> 
> http://magnifier.sourceforge.net/tmp/jfs_inode_10k_files.png
> 
> di_fileset $10
> di_number $303
> di_gen $2A
> di_size = $14000
> di_nblocks = $140
> di_nlink = 2
> di_uid = 0
> di_gid = 0
> di_mode = $200041FF
> di_next_index = $B0100
> di_acltype = 0
> 
> dtroot_t
> DASD = zeroes
> flag = 0x85 = DXD_INDEX | BT_INTERNAL | BT_ROOT
> nextindex = 1
> freecnt: int8 = 7
> freelistt: int8 = 2
> idotdot = $3040
> stbl = 1, 2, 4, 6, 8, 0, 0, 0
> 
> dir_table_slot[0]

Okay, di_dirtable is a bit of a mess. It's something I retro-fitted into
the directory inode in order to create a mapping from the readdir cookie
back to the directory entry corresponding to it. This allows a readdir
to always resume from the correct location. You should be able ignore it
completely when reading the inode.

For what it's worth, once the cookie index, di_next_index, goes above
MAX_INLINE_DIRTABLE_ENTRY (13), the table is overwritten with an
xtpage_t and the table is the data pointed to by the xtree. But you
don't really want to look here anyway. (See jfs_dirtable_inline().)

> dir_table_slot->rsrvd = 0
> dir_table_slot->flag = 1 DIR_INDEX_VALID
> dir_table_slot->slot = B
> dir_table_slot->addr1 = 0
> dir_table_slot->addr2 = $6023
> dir_table_slot[1]
> dir_table_slot = 0
> dir_table_slot->flag = 1  DIR_INDEX_VALID
> dir_table_slot->slot = 0
> dir_table_slot->addr1 = 0
> dir_table_slot->addr2 = $6023
> dir_table_slot[2]
> dir_table_slot->rsrvd = $85
> dir_table_slot->flag = 1 DIR_INDEX_VALID
> dir_table_slot->slot = 3
> dir_table_slot->addr1 = 0
> dir_table_slot->addr2 = 6
> dir_table_slot[3]
> dir_table_slot->rsrvd = 0
> dir_table_slot->flag = 1 DIR_INDEX_VALID
> dir_table_slot->slot = 2
> dir_table_slot->addr1 = 0
> dir_table_slot->addr2 = $6023
> dir_table_slot[4]
> dir_table_slot->rsrvd = 0
> dir_table_slot->flag = 1 DIR_INDEX_VALID
> dir_table_slot->slot = 3
> dir_table_slot->addr1 = 0
> dir_table_slot->addr2 = 0
> dir_table_slot[5]
> dir_table_slot->rsrvd = 1
> dir_table_slot->flag = 0 DIR_INDEX_FREE
> dir_table_slot->slot = 0
> dir_table_slot->addr1 = 0
> dir_table_slot->addr2= $801A
> etc
> etc
> 
> Which has the following problems:
> 
> 1> If I believe in freecnt 7 items should be free and only 1 valid?
> Which one? The first with address 0x6023? But in reality 0x6023
> contains some files, while 0x801A constains a list of blocks, so it
> cannot be that only 0x6023 is valid...

Yes, there are 7 free slots and 1 valid one. The valid one is stbl[0] =
1. The valid slots will be stbl[0..next_index-1].

But the slot you want is not in the dir_table, but the dtslot array in
hte dtroot_t structure.

slot[0] is never used because it overlays the header. (I'm not sure why
these types were defined as unions, but they are.)

Since this is an internal node, the slots are represented by idtentry_t.

slot[1].xd.length = 1
slot[1].xd.address = 0x80b4
slot[1].next = 0xFF
slot[1].namlen = 0

It seems the rest of your questions are a result of looking at the
dir_table rather than the dtroot_t slots.

> 2> dir_table_slot[5] with addr 0x801A should be valid, because if it
> is not, then I don't see how I could possibly have the names of all
> 10k files, since 0x6023 is filled with only some filenames, while
> 0x801A has links to many blocks of filenames. But 0x801A has
> flag=0=DIR_INDEX_FREE, why?
> 
> 3> dir_table_slot[2] has addr=6 which is obviously wrong, and this
> block (offset 0x6000) contains only zeroes. But slot[2] is listed in
> the stbl and even has flag = 1 = DIR_INDEX_VALID How to identify that
> it is invalid then?
> 
> 4> 801A is here: http://magnifier.sourceforge.net/tmp/jfs_block_801A.png
> 
> I assume that the structure is a xtpage_t followed by an array of xad:
> 
> xtpage_t->next = 0
> xtpage_t->prev = 0
> xtpage_t->flag = 2=BT_LEAF?
> xtpage_t->rsrvd1 = 0
> xtpage_t->nextindex= $16
> xtpage_t->maxentry = $100
> xtpage_t->rsrvd2 = 0
> 
> Strange here is the flag, I'd expect BT_INTERNAL, but it is BT_LEAF...
> 
> 801A links to 602A which links to 6083 which finally is a leaf block.
> But all 3 blocks have flag 2 set .... so how can I differentiate
> between a leaf (which I think should contain filenames) and an
> internal node (which I think should contain a list of blocks)?
> 
> 5> In block 602A there are multiple xad's referring to the exact same
> leaf blocks (0x6023 for example), the only difference between them
> being the reserved field:
> 
> http://magnifier.sourceforge.net/tmp/jfs_block_602A.png
> 
> xad[2]
> xad_t->flag = 0
> xad_t->rsvrd= $301
> xad_t->off1 = 0
> xad_t->off2= $6023
> xad_t->len = $60100
> xad_t->addr1 = 0
> xad_t->addr2 = $6023
> xad[3]
> xad_t->flag = 0
> xad_t->rsvrd = $501
> xad_t->off1 = 0
> xad_t->off2= $6023
> xad_t->len = $60100
> xad_t->addr1 = 0
> xad_t->addr2 = $6023
> 
> Is this information relevant for my software or should I just skip
> repeated blocks?
> 
> thanks =)
> 

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Jfs-discussion mailing list
Jfs-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jfs-discussion
[prev in list] [next in list] [prev in thread] [next in thread]