|
In last topic, we discussed recovery 'rm'ed file to original statues in IBM jfs1, here is the turn for jfs2
What 'rm' done to your file? pretty much 4 things:(there're some things done by OS instead rm self, we just don't care here).
1.changed the directory inode, in jfs1, rm changed last directory entry's record length to 'shield' the one you wanna remove. And in jfs2, rm changed B+ tree link. basicly reverse these operations before in either FS, you can get your file name back at original localtion. But these won't get your real file back.
2.changed the disk i-node, brake the i-node link to upper directory. so just reconnect it.this is the basic way I am using to recovry the file. But without reverse above No.1 step, we won't be able to get the file name back at original localtion.itjslt，数据库，路由器，交换机，小型机，IT技术文档. S* \+ k B6 _8 P* x
3.changed the i-node map, release the i-node from inode allocation map, so you can use it again. For reverse, yep, we can do it manual, but most time it's just too complication. I use fsck do the job. 2 f9 _: p# e" u- m" q8 K& R
4.changed the block map. release blocks to make them available again.So reverse, same as above, I use fsck.
jfs and jfs2 are using different names for these 4 things due to different terminology and construction, I just like to mix them, it's just not that important here. itjslt，数据库，路由器，交换机，小型机，IT技术文档) p" |- J7 i; ?$ M& {) O
Compare to AIX's jfs1, jfs2 is more complicated, it use a b+ tree to store directory entries instead linear records in jfs1. so this make it's little difficult to recover the file name in original location in jfs2 without knowing how IBM use the B+ tree to store directory entries which you can learn from /usr/include/j2. So I just simply skip this and also 3 & 4 of above, Just explain how to recover the file by re-link it in a very simple scenario, actually, just use 'fsdb' to set a trap for 'fsck', and let 'fsck' finish rest job. In a more complicated situation, this may or may not work, And for the rest or other methods for recovery files I just not discuss here, go learn by your self. fsdb and fsck are very powerful and low level tools, understand before use them, remember BACKUP and UMOUNT file system before do anything. Last, use this information under your own responsibility, and good luck（切记切记）.+ l
实验过程如下：
文件系统/test,下面有两个文件test1，test2
首先利用ls -id test可以知道文件夹test的inode号为2
# ls -id /test
2 /test
# ls -i /test/*
4 /test/test1 5 /test/test2
备注：test1的inode号为4，test2的inode号为5.
# rm /test/test1
# umount /test
# fsdb /test
File System: /test
File System Size: 523864 (512 byte blocks)
Aggregate Block Size: 4096
Allocation Group Size: 8192 (aggregate blocks)
> i 2
Inode 2 at block 33, offset 0x400:
[1] di_fileset: 16 [18] di_inostamp: 0x49ca2ecc
[2] di_number: 2 [19] di_gen: 1
[3] di_size: 0x0000000000000100 [20] di_ixpxd.len: 4
[4] di_nblocks: 0x0000000000000000 [21] di_ixpxd.addr1: 0x00
[5] di_nlink: 3 [22] di_ixpxd.addr2: 0x00000021
[6] di_mode: 0x000141ed di_ixpxd.address: 33
0040755 drwxr-xr-x [24] di_uid: 0
[25] di_gid: 0
[9] di_atime.tj_nsec: 0x04ef2f3a [26] di_atime.tj_sec:0x0000000049ca3144
[10] di_ctime.tj_nsec: 0x04ef2e18 [27] di_ctime.tj_sec:0x0000000049ca2fbe
[11] di_mtime.tj_nsec: 0x04ef2e18 [28] di_mtime.tj_sec:0x0000000049ca2fbe
[12] di_otime.tj_nsec: 0x00000000 [29] di_otime.tj_sec:0x0000000049ca2ecc
[13] di_ea.flag: 0x00 [30] di_ea.len: 0
EAv1 [31] di_ea.addr1: 0x00
[15] di_ea.nEntry: 0x00 [32] di_ea.addr2: 0x00000000
[16] di_ea.type: 0x0000 di_ea.address: 0
[34] di_ea.nblocks: 0
change_inode: [m]odify, [e]a, [t]ree, or e[x]it > t
Root D-Tree Node of inode 2
[1] flag 0x83 BT_ROOT BT_LEAF
[2] nextindex 2
[3] freecnt 6 Actual Free Count: 6
[4] freelist 2 type 'f' to walk
[5] idotdot 2
stbl {1,3,3,0,0,0,0,0} type '#' for specific stbl entry
Slots: next cnt type 's' to modify slot
slot[1]: 0 0
slot[2]: 4 1
slot[3]: 0 0
slot[4]: 5 1
slot[5]: 6 1
slot[6]: 7 1
slot[7]: 8 1
slot[8]: -1 1
dtree: Hit enter to see entries, [h]ex dump, [u]p, [m]odify, [f]reelist,
[s]lot, [#], or e[x]it: h
Slot: Inum Next NamLen Name
00000000: 00000000 00000002 00000000 00000000 |................|
00000010: 83020602 00000000 01030300 00000000 |................|
00000020: 00000000 00000003 FF0A6C6F 73742B66 |..........lost+f|
00000030: 6F756E64 00000000 00000000 00000000 |ound............|
00000040: 04010000 00000004 FF057465 73743100 |..........test1.|
00000050: 00000000 00000000 00000000 00000000 |................|
00000060: 00000000 00000005 FF057465 73743200 |..........test2.|
00000070: 00000000 00000000 00000000 00000000 |................|
00000080: 05010000 00000000 00000000 00000000 |................|
00000090: 00000000 00000000 00000000 00000000 |................|
000000a0: 06010000 00000000 00000000 00000000 |................|
000000b0: 00000000 00000000 00000000 00000000 |................|
000000c0: 07010000 00000000 00000000 00000000 |................|
000000d0: 00000000 00000000 00000000 00000000 |................|
000000e0: 08010000 00000000 00000000 00000000 |................|
000000f0: 00000000 00000000 00000000 00000000 |................|
-hit enter for more-
00000100: FF010000 00000000 00000000 00000000 |................|
00000110: 00000000 00000000 00000000 00000000 |................|
dtree: Press [u]p, [#], or e[x]it > x
备注：从上面其实可以看出，test1的inode号为4，test2的inode号为5.
> i 4
Inode 4 at block 33, offset 0x800:
[1] di_fileset: 16 [18] di_inostamp: 0x49ca2ecc
[2] di_number: 4 [19] di_gen: 787377383
[3] di_size: 0x0000000000000006 [20] di_ixpxd.len: 4
[4] di_nblocks: 0x0000000000000001 [21] di_ixpxd.addr1: 0x00
[5] di_nlink: 0 [22] di_ixpxd.addr2: 0x00000021
[6] di_mode: 0x000081a4 di_ixpxd.address: 33
0100644 -rw-r--r-- [24] di_uid: 0
[25] di_gid: 0
[9] di_atime.tj_nsec: 0x0882b663 [26] di_atime.tj_sec:0x0000000049ca2f06
[10] di_ctime.tj_nsec: 0x04ef2e18 [27] di_ctime.tj_sec:0x0000000049ca2fbe
[11] di_mtime.tj_nsec: 0x091b4cb9 [28] di_mtime.tj_sec:0x0000000049ca2f06
[12] di_otime.tj_nsec: 0x0882b663 [29] di_otime.tj_sec:0x0000000049ca2f06
[13] di_ea.flag: 0x00 [30] di_ea.len: 0
EAv1 [31] di_ea.addr1: 0x00
[15] di_ea.nEntry: 0x00 [32] di_ea.addr2: 0x00000000
[16] di_ea.type: 0x0000 di_ea.address: 0
[34] di_ea.nblocks: 0
change_inode: [m]odify, [e]a, [t]ree, or e[x]it > m 5 1
Inode 4 at block 33, offset 0x800:
[1] di_fileset: 16 [18] di_inostamp: 0x49ca2ecc
[2] di_number: 4 [19] di_gen: 787377383
[3] di_size: 0x0000000000000006 [20] di_ixpxd.len: 4
[4] di_nblocks: 0x0000000000000001 [21] di_ixpxd.addr1: 0x00
[5] di_nlink: 1 [22] di_ixpxd.addr2: 0x00000021
[6] di_mode: 0x000081a4 di_ixpxd.address: 33
0100644 -rw-r--r-- [24] di_uid: 0
[25] di_gid: 0
[9] di_atime.tj_nsec: 0x0882b663 [26] di_atime.tj_sec:0x0000000049ca2f06
[10] di_ctime.tj_nsec: 0x04ef2e18 [27] di_ctime.tj_sec:0x0000000049ca2fbe
[11] di_mtime.tj_nsec: 0x091b4cb9 [28] di_mtime.tj_sec:0x0000000049ca2f06
[12] di_otime.tj_nsec: 0x0882b663 [29] di_otime.tj_sec:0x0000000049ca2f06
[13] di_ea.flag: 0x00 [30] di_ea.len: 0
EAv1 [31] di_ea.addr1: 0x00
[15] di_ea.nEntry: 0x00 [32] di_ea.addr2: 0x00000000
[16] di_ea.type: 0x0000 di_ea.address: 0
[34] di_ea.nblocks: 0
change_inode: [m]odify, [e]a, [t]ree, or e[x]it > x
> q
# fsck /test
The current volume is: /dev/testlv
Primary superblock is valid.
*** Phase 1 - Initial inode scan
*** Phase 2 - Process remaining directories
*** Phase 3 - Process remaining files
*** Phase 4 - Check and repair inode allocation map
File system inode map is corrupt; FIX? y
Superblock marked dirty because repairs are about to be written.
*** Phase 5 - Check and repair block allocation map
Block allocation map is corrupt; FIX? y
Inodes not connected to the root directory
tree have been detected. Will reconnect.
File system is clean.
Superblock is marked dirty; FIX? y
All observed inconsistencies have been repaired.
# mount /test
# ls -l
total 8
-rw-r--r-- 1 root system 6 Mar 25 22:17 4
# more 4
test1
备注：文件test1中的内容只有一行，就是test1.
# mv 4 ../test1
# ls
# cd /test
# ls
lost+found test1 test2
# ls -l
total 16
drwxr-xr-x 2 root system 256 Mar 25 22:55 lost+found
-rw-r--r-- 1 root system 6 Mar 25 22:17 test1
-rw-r--r-- 1 root system 6 Mar 25 22:18 test2
| 