On Mon, Apr 17, 2006 at 07:07:28PM +0400, unDEFER wrote:
> Hello!
Hi there,
> I try to understand XFS structure (I need it so as I will write build_xfs
> util like build_e2fs for anyfs-tools.sf.net project) and have some
> questions.
> I have understood superblock structure, alocation and inode allocation
> B-trees structures, inode core, extent list and directory structures, but
> I have some problem with Block Map.
> According information in xfsprogs-2.7.11/include/xfs_dinode.h, if
> di_format field of di_core have value 3 (XFS_DINODE_FMT_BTREE), then union
> inode have xfs_bmdr_block_t structure format, but seems it is not so.
> Below, I put some commented hexdump of structure of 0x84 inode (I expect,
> you have monospace type in your mail reader):
You should be able to figure out the answers to your questions
through clever use of xfs_db - something along the lines...
# xfs_db /dev/sdb5
xfs_db> sb
xfs_db> p rootino
rootino = 128
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.flushiter = 1
core.atime.sec = Thu Apr 13 16:30:06 2006
core.atime.nsec = 969575000
core.mtime.sec = Thu Apr 13 16:30:08 2006
core.mtime.nsec = 533941750
core.ctime.sec = Thu Apr 13 16:30:08 2006
core.ctime.nsec = 533941750
core.size = 21
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.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.gen = 0
next_unlinked = null
u.sfdir2.hdr.count = 1
u.sfdir2.hdr.i8count = 0
u.sfdir2.hdr.parent.i4 = 128
u.sfdir2.list[0].namelen = 8
u.sfdir2.list[0].offset = 0x30
u.sfdir2.list[0].name = "4100.tmp"
u.sfdir2.list[0].inumber.i4 = 131
xfs_db> type text
xfs_db> p
00: 49 4e 41 ed 01 01 00 02 00 00 00 00 00 00 00 00 INA.............
10: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 01 ................
20: 44 3d ef ee 39 ca 8a 58 44 3d ef f0 1f d3 4d f6 D...9..XD.....M.
30: 44 3d ef f0 1f d3 4d f6 00 00 00 00 00 00 00 15 D.....M.........
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
50: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 ................
60: ff ff ff ff 01 00 00 00 00 80 08 00 30 34 31 30 ............0410
70: 30 2e 74 6d 70 00 00 00 83 00 00 00 00 00 00 00 0.tmp...........
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
xfs_db>
and now with some cunning use of xfs_io to setup inodes into their
various states, you're able to figure out the entire ondisk state
of all the different file types.
Don't put too much faith in the comments and those unions over in
dinode.h - the unions in particular are not like that on-disk - we
keep those there mainly for documentation I guess. In particular,
there will often be multiple copies of one of the entries from that
union, and the attr fork "union" doesn't follow immediately after
the data fork "union" ondisk.
Good luck.
cheers.
--
Nathan
|