折腾了一晚上的fsdb,还是没弄懂？

看了rm的那个帖子，折腾了一晚上的fsdb，还是没有弄成功，那位老大能详细讲讲，怎么用fsdb恢复数据啊？这一招真的很吊

建了1个/dev/fslv02,/test2,文件1.log

rm 1.log
ls -id /test2
2
umount /test2
fsdb /test(红的是我输的)

2i
i#:      2  md: d-g-rwxr-xr-x  ln:    3  uid:    3  gid:    3
szh:        0  szl:      512  (actual size:      512)
a0: 0x0b        a1: 0x00        a2: 0x00        a3: 0x00        
a4: 0x00        a5: 0x00        a6: 0x00        a7: 0x00        
at: Sun Jan 04 08:18:53 2009
mt: Sun Jan 04 08:18:40 2009
ct: Sun Jan 04 08:18:40 2009

a0b
0x000000b000  :  0x00000000 (0)

p128c
0x000000b000:   \0 \0 \0 \? \0 \? \0 \? .  \0 \0 \0 \0 \0 \0 \?
0x000000b010:   \0 \? \0 \? .  .  \0 \0 \0 \0 \0 \? \? ? \0 \n
0x000000b020:   l  o  s  t  +  f  o  u  n  d  \0 \0 \0 \0 \0 \?
0x000000b030:   \? ? \0 \? 1  .  l  o  g  \0 \0 \0 \0 \0 \0 \0
0x000000b040:   \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0x000000b050:   \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0x000000b060:   \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0x000000b070:   \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0

p128e

0x000000b000:         0       2      12       1   11776       0       0       2
0x000000b010:        12       2   11822       0       0      16     488      10
0x000000b020:     27759   29556   11110   28533   28260       0       0      17
0x000000b030:       468       5   12590   27759   26368       0       0       0
0x000000b040:         0       0       0       0       0       0       0       0
0x000000b050:         0       0       0       0       0       0       0       0
0x000000b060:         0       0       0       0       0       0       0       0
0x000000b070:         0       0       0       0       0       0       0       0
0x000000b080:         0       0       0       0       0       0       0       0
0x000000b090:         0       0       0       0       0       0       0       0
0x000000b0a0:         0       0       0       0       0       0       0       0
0x000000b0b0:         0       0       0       0       0       0       0       0
0x000000b0c0:         0       0       0       0       0       0       0       0
0x000000b0d0:         0       0       0       0       0       0       0       0
0x000000b0e0:         0       0       0       0       0       0       0       0
0x000000b0f0:         0       0       0       0       0       0       0       0


后面就不太懂了，要修改什么，又怎么修改，谁来讲讲啊！

附上ibm上的文档，http://www-01.ibm.com/support/do ... 71b48256d40001f7b87

Jfs/jfs2恢复文件/目录的办法不止那一个。

fsdb的接触层面非常低了，你必须明白jfs1和jfs2的不同layout，jfs使用线性记录，jfs2使用B-tree，遍历办法不同。因此fsdb对jfs1和jfs2有完全不同的界面和子命令。

而且原来rm的帖子的文章只写了对jfs的操作过程，而没有告诉你原理，甚至计算大inode number的方法都没有讲。而且最终需要依赖fsck找回文件放在lost+found下。

man fsdb

p128d  d是以目录格式显示 这样就会很清楚

如果删除文件，那么目录中的变化就是，这个被删除文件的上一个文件的名字长度会加长，把被删除文件的目录项覆盖

把长度给改回来，在fsck就可能恢复出来

好像是这样，记不清了，主要用d这个参数就很容易看懂了

做个记号，明天来玩玩

先看一下

有什么更好的方法可以恢复rm的数据呢？我google了很多，基本都是那篇fsdb的文档啊。

就以你的例子解释。
首先说明，这些操作只对jfs1有效，jfs2有不同。#后是注释。麻烦自己识别字符，16进制和10进制数据及转换，以下不会特别注明。

ls -id /test2  #找文件系统目录i-node,这里用楼主inode 2
unmount /test2  

fsdb /test2  #启动fsdb

2i  #指向目录inode

a0b #指向第一个block. 通常jfs的目录会先占用头512byte, 如果不够会延伸4096byte. 所以要找的文件如果不在第一个block, 看后面的。

p128c  #字符形式显示前128，所以你显示256或者512也行，但一般都没有必要。

a0b     #必须输入，使指针回到 a0 处，否者显示的是下一个128.

p128e  #e为显示十进制数据。

0x000000b000:         0       2      12       1   11776       0       0       2
0x000000b010:        12       2   11822       0       0      16     488      10
0x000000b020:     27759   29556   11110   28533   28260       0       0      17
0x000000b030:       468       5   12590   27759   26368       0       0       0
0x000000b040:         0       0       0       0       0       0       0       0
0x000000b050:         0       0       0       0       0       0       0       0
0x000000b060:         0       0       0       0       0       0       0       0
0x000000b070:         0       0       0       0       0       0       0       0
0x000000b080:         0       0       0       0       0       0       0       0
0x000000b090:         0       0       0       0       0       0       0       0
0x000000b0a0:         0       0       0       0       0       0       0       0
0x000000b0b0:         0       0       0       0       0       0       0       0
0x000000b0c0:         0       0       0       0       0       0       0       0
0x000000b0d0:         0       0       0       0       0       0       0       0
0x000000b0e0:         0       0       0       0       0       0       0       0
0x000000b0f0:         0       0       0       0       0       0       0       0

#这里的关键是数据结构， i-node占前两位，然后是记录长度一位，然后是文件名长度一位，然后是文件名，这里不考虑长文件名和长目录记录的状况。你在p128c的时候可以看到被删除文件的文件名1.log, 这时可以记录文件名开始的位置0xb035，实际来说因为操作在同一屏幕对照看就行了。那么看p128e中0xb035的位置，是12590，这实际是1.log的开始位置，之前的5就是文件名长度，468就是记录长度，0和17就是inode。这里就涉及到计算的问题，原文很是模糊，这里是我的办法，当inode大于255的时候，也就是第一位也有数据那么就是：第一个数据x65536+第二位数据=inode, 这里就是0x65536+17=17.  这个数据其实p128d也能看得非常清楚，但明白起见，这里用p128e来看。

#题外一点，这里可以看到1.log的记录长度是468，也就是cover了512byte中除了前面数据剩下的全部数据，这也是告诉文件系统我后面没文件了，确实后面全是0。再看前面一条记录lost+found记录长度竟然是488,为什么？因为1.log被删除了，系统读lost+found记录时就认为后面没有记录了，如果1.log没有被删除，那么lost+found的记录长度就应该是20. 不信在删除前可以看看。系统是根据记录长度和文件名长度来读取文件名的，根据inode来找到真实数据的。在下一个文件名/目录名没有被写入时，我们都能将他们找回。

#然后的步骤就是看真实inode.LZ例子
17i
#这里会有"ln 0”显示。也就是说接下来的数据没有被链接。
17i.ln=1 #修改inode数据，将ln改为1，也就是告诉文件系统我是有用的，不过有错误而已。验证一下17i，这是ln 就会是1了。

q #退出fsdb

然后

fsck /dev/fslv02 #无需mount,也不建议mount检查文件系统，所有选项都是yes.

完成后
mount /test2

去lost+found你会找到类似17文件名的文件，这就是你要的文件，
cp /test/lost_found/17 /test/1.log.  #实际情况中除非你删掉的是目录中第一个记录，在不修改目录数据中丢失文件前一文件的记录长度时，不可能fsck后修复的文件以原始文件名还原到原始位置。至于如何修改前一记录长度涉及一点计算和修改操作，具体就man fsdb得了。

记住以上操作是基于jfs1，数据的记录方式是线性的，操作相对显而易见。jfs2用b-tree, 实际也无非找回家长树叶之类的，但相对非常灵活，在缺乏文档时理解和操作会更困难点。另外更高档一点修复丢失文件方式是snapshot或者logredo, 这毕竟是Journaled File System，也就是操作有记录并可回复的。

BTW，IBM的同学也确实要提高一下了，自己的东西拿人家的文章都不能解释清楚一点。

[ 本帖最后由 projects 于 2009-1-5 03:45 编辑 ]

好人做到底，接下来玩一下如何直接回复文件名到原始目录，也就是IBM文章的第二部分，但他们写得太confuse了。我们可以用上面tenyears的idea
还是以上面LZ操作为例.
当操作到17i.ln=1的时候不退出fsdb
而是从新回到目录inode, (这一步早过修改数据inode链接都可，一定要注意指针指向正确的节点和block)

2i #指向目录inode
a0b #指向a0 block
p128d  #显示目录结构

删除1.log后应该显示(模拟的，具体可能有不同)
d0 (slot=0):    2  . (d_reclen/d_namlen = 12/1)
d1 (slot=12):    2  .. (d_reclen/d_namlen = 12/2)
d2 (slot=24):   16  lost+found (d_reclen/d_namlen = 488/10)
d4 (slot=512):    0   (d_reclen/d_namlen = 512/0)
d5 (slot=1024):    0   (d_reclen/d_namlen = 512/0)
d6 (slot=1536):    0   (d_reclen/d_namlen = 512/0)
d7 (slot=2048):    0   (d_reclen/d_namlen = 512/0)
d8 (slot=2560):    0   (d_reclen/d_namlen = 512/0)
d9 (slot=3072):    0   (d_reclen/d_namlen = 512/0)
d10 (slot=3584):    0   (d_reclen/d_namlen = 512/0)

d2.rl=20  #d2是你需要修改的记录(你删除文件前的一项)，rl是fsdb里用来改变记录长度(d_reclen)的子命令, 20是在p128e时488-468=20得出的，但实际上人工也可以数出来。

然后
a0b #回到a0

p128d #验证一下

会显示
d0 (slot=0):    2  . (d_reclen/d_namlen = 12/1)
d1 (slot=12):    2  .. (d_reclen/d_namlen = 12/2)
d2 (slot=24):   16  lost+found (d_reclen/d_namlen = 20/10)
d3 (slot=60):   17  1.log (d_reclen/d_namlen = 468/5)
d4 (slot=512):    0   (d_reclen/d_namlen = 512/0)
d5 (slot=1024):    0   (d_reclen/d_namlen = 512/0)
d6 (slot=1536):    0   (d_reclen/d_namlen = 512/0)
d7 (slot=2048):    0   (d_reclen/d_namlen = 512/0)
d8 (slot=2560):    0   (d_reclen/d_namlen = 512/0)
d9 (slot=3072):    0   (d_reclen/d_namlen = 512/0)
d10 (slot=3584):    0   (d_reclen/d_namlen = 512/0)

q  #退出

fsck /dev/fslv02  #这只是为了保证文件系统的完整性. 实际上此时文件已经回到了原始的位置，而且毫发无损。你可以跳过这一步验证一下。因为rm除了修改了目录inode中前一记录长度和数据inode ln之外也修改了i-node map &/block map，而我们并没有改回，如果不做fsck，文件虽然可用，但此时文件系统的完整性得不到保证。

mount /test2

文件就在那里了。

到此，对rm jfs文件系统基本可以算完美了，整个过程主要依赖于fsdb和fsck来实现，fsdb是相当底层的工具，相比而言，fsck高层很多，可实现的功能更为复杂，以上的rm修复实际上两个步骤中单独一样+fsck都可以恢复，解释一下也就是方便大家搞明白原理。BTW 有谁弄明白了，大可以整理一下把两篇合二为一赚个精华也可以，标上lu和projects转载也行。Jfs2要复杂不少，打字太累了，有能力还是自己玩吧。good luck。

[ 本帖最后由 projects 于 2009-1-5 03:58 编辑 ]

projects 牛

终于看到一篇说的比较清楚的了

不错,好好研究一下

projecs，只能说我对你的敬仰犹如滔滔江水，连绵不绝…………

太强大了，我我我要认真学习

经典教学帖..学习了~~谢谢~

很奇怪的问题，我按照project的方法做了，可以恢复出文件，但是用ls -l，就停在那里了，但是用ls就可以显示文件，是咋回事情啊？

嗯，不错，收藏一下 有空玩玩

It happens. You may get the file name back, but no content; you may fix the link and file name, but did not fix the i-node map etc, that's why run fsck with file system unmount after. just be careful about your operations. check yourself. esp, point location, like which inode number you're running under, which block you are pointing to. Try to understand before do anything.

Also make a file with content for test, not just empty file. Otherwise u won't be able tell if you just get file name back or real file back. Also make more than one file under your test directory, compare data before rm and after, you will get more clear image that what you are doing.

Good luck.

[ 本帖最后由 projects 于 2009-1-5 12:23 编辑 ]

咋说呢，只有一个字，“牛”

这个贴技术含量高。路过补个钙

LU的技术专家，都不是一般的牛

project是不是在国外啊？

他在美国

创建一个jfs文件系统/test，并复制一个约51MB的文件aaa进去，然后再复制一份，叫做zzz，则/test下有两个内容一样的文件aaa,zzz。并用fsdb查看正常的目录inode



以上看到，文件aaa的inode号是00 00 00 11=17，记录长度是00 0C=12。文件zzz的inode号是00 00 00 12=18，记录长度是01 C8=456。

删除zzz，并作fsdb，先用第二种方法恢复，就是尝试将文件直接恢复到原目录原名称的方法，inode 18的link(ln)设置为1，然后修改前面一个文件aaa的记录长度为12（恢复成原样）。



删除zzz之后，aaa的记录长度从12变为01 D4=468，修改回12。先不mount，直接fsck，就已经有错了，说明zzz的inode map有不同于原来的地方，而方法中没有讲到对此可能有恢复的需要。



重新修改aaa的记录长度为zzz删除之后的状态，d3.rl=468，即回滚第二种方法多出的步骤，成为第一种方法，然后试图依赖fsck将文件自动恢复到lost+found



补丁集是AIX 5.3 TL7 SP6

fsck的结果一样有错，说明zzz的inode map确实在删除时有变化而没有恢复到。
这里我是中断了fsck，我做了试验，如果一路敲y让它修复下去，最后的结果，轻则对恢复出来的文件做sum，结果与sum aaa不一样，重则一访问zzz，机器就重启！

[ 本帖最后由 larryh 于 2009-1-5 16:59 编辑 ]

神仙也来凑热闹。

也搞了一把， 数据没有还原， cat出来是空的。。。。

还没有试过，改天也要试下。先瞻仰一下前辈们的经验。

不过试了一下project说的snapshot，挺好玩。

bash-3.00# snapshot -q /ngd
Snapshots for /ngd
Current  Location        512-blocks  Free        Time
         /dev/fslv15     65536       64768       Mon Jan  5 15:05:29 BEIST 2009
*        /dev/fslv16     32768       29184       Mon Jan  5 15:11:14 BEIST 2009
bash-3.00#

但是也有缺点
bash-3.00# chfs -a size=1G /ngd
chfs: 0506-957 Shrinking filesystem with a snapshot is not supported.
bash-3.00#

project说的logredo还不知道咋用。

数据恢复，就不是一个简单的活。

很久不见技术贴了。。。。顶下

很强大啊！

没细看，一般来说最后运行fsck就是来修复inode map和block map的。另外可能跟你的43p150--32位系统有关。

你的lost+found 下有两个文件？

也真是，larryh怎么还用150啊

初略试了一下，
rm test/zzz
和
cd test
rm zzz
好像不同的，后者恢复没有问题，前者恢复后有时是空文件或者文件size内容都不对，但也有成功。

另外怀疑fsck phase1 check log，在一定情况下会做log redo, 这会对原始文件造成影响。

[ 本帖最后由 projects 于 2009-1-6 00:52 编辑 ]