On Mar 19, 2018, at 6:19 PM, Jidong Xiao <0121167@xxxxxxxxxxxx> wrote: >> -----Original Messages----- >> From: "Andreas Dilger" <adilger@xxxxxxxxx> >> Sent Time: 2018-03-20 07:46:23 (Tuesday) >> To: "Jidong Xiao" <0121167@xxxxxxxxxxxx> >> Cc: linux-ext4@xxxxxxxxxxxxxxx >> Subject: Re: No data blocks at all in my ext4 journal >> >> On Mar 19, 2018, at 5:31 PM, Jidong Xiao <0121167@xxxxxxxxxxxx> wrote: >>> >>> Hi, >>> >>> When I use the dd command to examine the journal, it turns out every block starts with the jbd2 magic number, meaning they are either a superblock, a descriptor block, or a commit block, or a revoke block, but there is no data block. >>> >>> I manually and randomly tried like 50 blocks after that superblock, but I haven't seen any data blocks. >>> >>> The kernel version I am using is, 4.14. Is this a serious bug or am I doing something wrong? Anyone has any suggestions, or tell me how to find the data blocks in my journal, or are they actually missing from the journal? By data blocks, I mean metadata, as my system is using the default mode, i.e., the ordered journal mode, only metadata will be logged. >>> >>> Thanks. Let me know if more information is needed. >> >> You can decode the journal structure using debugfs, and it will show you the >> blocks more easily: >> >> # debugfs -c -R "logdump -a" /dev/vg_mookie/lv_root >> debugfs 1.42.13.wc5 (15-Apr-2016) >> Journal starts at block 13970, transaction 1103250 >> Found expected sequence 1103250, type 1 (descriptor block) at block 13970 >> Dumping descriptor block, sequence 1103250, at block 13970: >> FS block 12058640 logged at journal block 13971 (flags 0x0) >> FS block 3 logged at journal block 13972 (flags 0x2) >> FS block 12059015 logged at journal block 13973 (flags 0x2) >> FS block 12058703 logged at journal block 13974 (flags 0x2) >> FS block 12066941 logged at journal block 13975 (flags 0x2) >> FS block 12058641 logged at journal block 13976 (flags 0x2) >> FS block 12059178 logged at journal block 13977 (flags 0x2) >> FS block 0 logged at journal block 13978 (flags 0xa) >> Found expected sequence 1103250, type 2 (commit block) at block 13979 >> >> Cheers, Andreas >> >> > > Hi, Andreas, > > Thanks for your kindly response. > > I tried the TSK tool and debugfs, the results are the same, there is no data/metadata block in my journal. Every block is either a superblock, or a descriptor block, or a commit block. For example, using debugfs with the command you provided, I got this: > > [lab7]$ sudo debugfs -c -R "logdump -a" /dev/sda3 > Journal starts at block 7757, transaction 8305398 > Found expected sequence 8305398, type 1 (descriptor block) at block 7757 > Dumping descriptor block, sequence 8305398, at block 7757: > FS block 36700177 logged at journal block 7758 (flags 0x0) > FS block 9 logged at journal block 7759 (flags 0x2) > FS block 36700889 logged at journal block 7760 (flags 0x2) > FS block 36700501 logged at journal block 7761 (flags 0x2) > FS block 36709095 logged at journal block 7762 (flags 0x2) > FS block 36700161 logged at journal block 7763 (flags 0x2) > FS block 36700907 logged at journal block 7764 (flags 0x2) > FS block 0 logged at journal block 7765 (flags 0xa) > Found expected sequence 8305398, type 2 (commit block) at block 7766 > [REMOVED] > > And my journal superblock is at block 52461568, so journal block 7760 is file system block (52461568+7760)=52469328. This is not totally accurate. While the journal superblock is at block 52461568, it is not always true that the logical journal block 7760 is at 52461568+7760. Instead you should use "stat" to determine the journal inode number (this will be "8" for almost all filesystems), and then "stat <8>" to dump the blocks allocated to the journal inode, like: debugfs: stat <8> Inode: 8 Type: regular Mode: 0600 Flags: 0x80000 Generation: 0 Version: 0x00000000:00000000 User: 0 Group: 0 Size: 134217728 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 262144 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x4e1b45e2:00000000 -- Mon Jul 11 12:50:10 2011 atime: 0x4e1b45e2:00000000 -- Mon Jul 11 12:50:10 2011 mtime: 0x4e1b45e2:00000000 -- Mon Jul 11 12:50:10 2011 crtime: 0x4e1b45e2:00000000 -- Mon Jul 11 12:50:10 2011 Size of extra inode fields: 28 EXTENTS: (0-32766):6324224-6356990, (32767):6356991 In my case, it shows that all 32768 blocks are physically contiguous on disk, so direct block addition will work, but that may not be the case if the journal was (re)created after the filesystem was formatted for some reason, or if it is so large that it crosses a group descriptor boundary. > Now I use dd command to examine 52469328, and I see this: > > [lab7]$ sudo dd if=/dev/sda3 bs=4096 skip=52469328 | xxd | more > 00000000: c03b 3998 0000 0002 007e a8cd 0000 0000 .;9......~...... > 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > 00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > 00000030: 0000 0000 5aaf 8011 16ca 442c 0000 0000 ....Z.....D,.... > 00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > > As you can see, debugfs says this is a journal metadata block records a file system block 36700889, yet the dd command says this is a journal commit block. I tried many journal blocks, and I don't see any metadata/data blocks in my journal. For example, these are the neighbor journal blocks: I did a similar comparison in my filesystem and things look as expected. In my above logdump, block #3 is at journal block 13972, and the journal superblock is at block 6324224, so it is block 6338196 on the disk: # dd if=/dev/vg_mookie/lv_root count=1 bs=4096 skip=3 | od -Ax -tx4 | head 000000 00800000 00800010 00800020 0751583d 000010 00040694 00000000 00000000 112c0000 000020 00800001 00800011 00800220 1c581692 000030 00040056 00000000 00000000 aae40000 000040 00800002 00800012 00800420 191b214e <==== this is modified in journal 000050 000400a5 00000000 00000000 31771575 000060 00800003 00800013 00800620 20006380 000070 00050000 00000000 00000000 fa6f2000 000080 00800004 00800014 00800820 20006d83 000090 00050000 00000000 00000000 7fff2000 # dd if=/dev/vg_mookie/lv_root count=1 bs=4096 skip=6338196 | od -Ax -tx4 | head 000000 00800000 00800010 00800020 0751583d 000010 00040694 00000000 00000000 112c0000 000020 00800001 00800011 00800220 1c581692 000030 00040056 00000000 00000000 aae40000 000040 00800002 00800012 00800420 191b214f <==== is 0x214e in filesystem 000050 000400a5 00000000 00000000 cd261575 000060 00800003 00800013 00800620 200063a9 000070 00050000 00000000 00000000 aeb72000 000080 00800004 00800014 00800820 20006d83 000090 00050000 00000000 00000000 7fff2000 The two blocks are nearly identical, except for byte 0x4f, which has changed value from 0x4e to 0x4f in the journal. According to "dumpe2fs -x", block #3 is a group descriptor block, and this block describes the groups 256-377. The word in question (0x214e = 8526) is the group 258 free blocks count: Group 258: (Blocks 0x810000-0x817fff) [ITABLE_ZEROED] Checksum 0x3177, unused inodes 5493 Block bitmap at 0x800002 (bg #256 + 2), Inode bitmap at 0x800012 (bg #256 + 18) Inode table at 0x800420-0x80061f (bg #256 + 1056) 8526 free blocks, 6427 free inodes, 165 directories, 5493 unused inodes It looks like some block was allocated or freed in this block group, but there are other journal blocks that must also be changing this value. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
