[Ocfs2-tools-devel] debugfs.ocfs2: How to use subcommands - 'dx_dump' and 'extent'
Zhen Ren
zren at suse.com
Tue Jul 28 00:58:01 PDT 2015
Hi gang,
Thanks a lot! But actually I used the correct block number.
I've figured out the root cause after I changed the block size from 4KB to 512Bytes.
Data in file is maintained in a B-tree of extents. So, there is no intermediate node, e.g., "extent block" for 0 level tree
because the 7g file is still small regarding 4KB block size.
For 'dx_dump', ocfs2 also maintained a separate indexed tree based on the hash of directory name. To search a dir entry
needs two step:
1. using hash index to find the directory block (4KB previously) in the indexed dir tree;
2. then search linearly in this block;
For my case, a 4KB block can hold all of the ocfs2-tools source entry.
So, it shows nothing because there is no tree yet.
Thanks again.
>>>
> Hi Zhen,
>
> The sub command is not mis-functional.
> please use the correct block number as input argument.
>
> for example,
> debugfs: stat dir.3019
> Inode: 92719 Mode: 0777 Generation: 2675869844 (0x9f7e8894)
> FS Generation: 2953544313 (0xb00b8279)
> CRC32: 00000000 ECC: 0000
> Type: Directory Attr: 0x0 Flags: Valid
> Dynamic Features: (0x8) IndexedDir
> User: 0 (root) Group: 0 (root) Size: 241664
> Links: 2 Clusters: 8
> ctime: 0x55b7179c 0x1b7ee329 -- Tue Jul 28 13:48:12.461300521 2015
> atime: 0x55b717a6 0x62e1b90 -- Tue Jul 28 13:48:22.103685008 2015
> mtime: 0x55b7179c 0x1b7ee329 -- Tue Jul 28 13:48:12.461300521 2015
> dtime: 0x0 -- Thu Jan 1 08:00:00 1970
> Refcount Block: 0
> Last Extblk: 0 Orphan Slot: 0
> Sub Alloc Slot: 0 Sub Alloc Bit: 7
> Indexed Tree Root: 69153
> Tree Depth: 0 Count: 243 Next Free Rec: 1
> ## Offset Clusters Block# Flags
> 0 0 8 10803280 0x0
>
> debugfs: dx_root <69153>
> Dir Index Root: 69153 FS Generation: 2953544313 (0xb00b8279)
> Clusters: 8 Last Extblk: 0 Dir Inode: 92719
> Sub Alloc Slot: 0 Sub Alloc Bit: 1
> Flags: (0x0)
> Total Entry Count: 10002
> CRC32: 00000000 ECC: 0000
> Tree Depth: 0 Count: 243 Next Free Rec: 8
> ## Offset Clusters Block# Flags
> 0 0 1 10803408 0x0
> 1 464146762 1 10803464 0x0
> 2 917925469 1 10803432 0x0
> 3 1511702967 1 10803448 0x0
> 4 1963815431 1 10803416 0x0
> 5 2450500483 1 10803456 0x0
> 6 2974120705 1 10803424 0x0
> 7 3697298737 1 10803440 0x0
>
>
>
>
> Thanks
> Gang
>
>
--
Eric, Ren
>>>>
> > Hi all,
> >
> > I'm very confused by how to use subcommands of debugfs - 'dx_dump' and
> > 'extent'.
> >
> > Quote from man page about debugfs.ocfs2:
> > ...
> > dx_dump filespec
> > Display the indexed directory information for the given
> > directory.
> > extent <block#>
> > Display the contents of the extent structure at block#.
> > ...
> >
> > 1. dx_dump
> > I am on a well-worked 3 nodes cluster.
> > Step 1: move ocfs2-tools source (it has directory tree) to
> /mnt/shared(shared
> > disk mount point);
> > Step 2: ls -R - in case it needs to generate indexed directory struct in
> > memory. I don't know much about indexed directory;
> > Step 3: debugfs.ocfs2 -> open device -> 'dx_dump /ocfs2-tools' or 'dx_dump
> > <139801>', it show nothing, but "lines ?-?/? (END)
> > "
> >
> > And 'stats' show that "indexed-dirs" feature is on.
> >
> >
> > 2.extent
> > Step 1: created a 5G large file by 'fallocate -l 7G 7g-file.img' in
> > /mnt/shared/;
> > Step 2: stat /7g-file.img, the output is:
> >
> > Inode: 193645 Mode: 0644 Generation: 745361378 (0x2c6d4fe2)
> > FS Generation: 3527657941 (0xd243c9d5)
> > CRC32: 00000000 ECC: 0000
> > Type: Regular Attr: 0x0 Flags: Valid
> > Dynamic Features: (0x0)
> > User: 0 (root) Group: 0 (root) Size: 7516192768
> > Links: 1 Clusters: 1835008
> > ctime: 0x55b5f1a9 0x2f571f34 -- Mon Jul 27 16:54:01.794238772 2015
> > atime: 0x55b5f1a9 0x26fee434 -- Mon Jul 27 16:54:01.654238772 2015
> > mtime: 0x55b5f1a9 0x2f571f34 -- Mon Jul 27 16:54:01.794238772 2015
> > dtime: 0x0 -- Thu Jan 1 08:00:00 1970
> > Refcount Block: 0
> > Last Extblk: 0 Orphan Slot: 0
> > Sub Alloc Slot: 0 Sub Alloc Bit: 108
> > Tree Depth: 0 Count: 243 Next Free Rec: 57
> > ## Offset Clusters Block# Flags
> > 0 0 32255 225793 0x1 Unwritten
> > 1 32255 32255 290305 0x1 Unwritten
> > 2 64510 32255 322561 0x1 Unwritten
> > 3 96765 32255 354817 0x1 Unwritten
> > 4 129020 32255 387073 0x1 Unwritten
> > 5 161275 32255 419329 0x1 Unwritten
> > ...
> > 52 1677260 32255 1967617 0x1 Unwritten
> > 53 1709515 32255 1999873 0x1 Unwritten
> > 54 1741770 32255 2032129 0x1 Unwritten
> > 55 1774025 32255 2064385 0x1 Unwritten
> > 56 1806280 28728 2096641 0x1 Unwritten
> >
> >
> >
> > Step 3: extent <2096641>, and other blockno in filed Block#, but it always
> > shows:
> >
> > debugfs: extent <2096641>
> > extent: Bad magic number in extent block while reading extent block 2096641
> >
> > And I also notice this info - " Last Extblk: 0 ".
> > Why the Last Exblk is 0, even for 7G large file?
> >
> > I don't know much about extent block mechanism. Please correct me with
> your
> > experience;-)
> >
> > --
> > Eric, Ren
> >
> >
> >
> >
> >
> > _______________________________________________
> > Ocfs2-tools-devel mailing list
> > Ocfs2-tools-devel at oss.oracle.com
> > https://oss.oracle.com/mailman/listinfo/ocfs2-tools-devel
>
> _______________________________________________
> Ocfs2-tools-devel mailing list
> Ocfs2-tools-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-tools-devel
>
>
More information about the Ocfs2-tools-devel
mailing list