Restore file with big inode number fail
Closed this issue · 5 comments
zzwwcc88 commented
Hello, author!
My test scenario is to delete all files in the /testdir directory. During my test, I found that this tool cannot recover files with inode number jumps, which often occurs in multi-level directories, or files with larger inode numbers cannot be recovered. Even if the inode number is specified with the -s parameter, it cannot be recovered. For example, files with inode numbers of 50-110 can be restored, while files with numbers of 13581-13590 and 1069121-1069129 cannot be restored. How to solve this situation?
ianka commented
Could you describe the problem more in detail?
It's perfectly normal that inode numbers aren't consecutive. Xfs_undelete does not count those numbers up itself. Instead, it walks the inode tree and takes the inode numbers as identifiers only. If you use the -s option, you have to specify an existing inode number. As the tool still walks the tree from the very beginning but does not try to recover anything until that exact inode number specified is found.
zzwwcc88 commented
Dear ianka, Hello!
My question is described in detail below. The operating system versions I tested are as follows:
Linux linuxz 3.10.0-957.axs7.x86_ 64 #1 SMP Sun May 24 08:42:07 CST 2020 x86_ 64 x86_ 64 x86_ 64 GNU/Linux
The directory structure I tested has the following two cases:
——————————————————situation one——————————————————
***@***.*** zwc]# ls -lirtR
.:
总用量 545296
67 drwxrwxr-x. 2 elastic elastic 6 7月 29 14:02 iamela
68 -rw-r--r--. 1 root root 6 7月 31 10:37 123.txt
69 -rw-r--r--. 1 root root 2 7月 31 10:37 1.txt
70 -rw-r--r--. 1 root root 2 7月 31 10:37 2.txt
71 -rw-r--r--. 1 root root 2 7月 31 10:37 3.txt
72 -rw-r--r--. 1 root root 3 7月 31 10:37 4.txt
73 -rw-r--r--. 1 root root 2 7月 31 10:37 5.txt
74 drwxr-xr-x. 2 root root 4096 7月 31 10:37 abc
99 -rw-r--r--. 1 root root 26664 7月 31 10:37 abc.zip
100 -rw-------. 1 root root 1157 7月 31 10:37 anaconda-ks.cfg
524416 drwxr-xr-x. 2 root root 219 7月 31 10:37 bcd
1069184 drwxr-xr-x. 2 root root 269 7月 31 10:37 cef
101 -rw-r--r--. 1 root root 69068800 7月 31 10:37 lib1.tar
102 -rw-r--r--. 1 root root 473753600 7月 31 10:37 lib.tar
103 -rw-r--r--. 1 root root 35149 7月 31 10:37 LICENSE
104 -rw-r--r--. 1 root root 1170791 7月 31 10:37 log1.tar.bz
105 -rw-r--r--. 1 root root 1170791 7月 31 10:37 log.tar.bz
106 -rw-r--r--. 1 root root 1774599 7月 31 10:37 log.tar.gz
107 -rw-r--r--. 1 root root 112 7月 31 10:37 loop-test.sh
108 -rw-------. 1 root root 28499 7月 31 10:37 messages
109 -rw-------. 1 root root 271793 7月 31 10:37 messages-20220410
110 -rw-------. 1 root root 628163 7月 31 10:37 messages-20220421
111 -rw-------. 1 root root 408352 7月 31 10:37 messages-20220424
112 -rw-------. 1 root root 674055 7月 31 10:37 messages-20220501
1732704 drwxr-xr-x. 2 root root 219 7月 31 10:37 pgarch
113 -rw-r--r--. 1 root root 12538 7月 31 10:37 README.md
114 -rw-r--r--. 1 root root 1739411 7月 31 10:37 report.xml
115 -rw-r--r--. 1 root root 150 7月 31 10:37 shell.nix
116 -rw-r--r--. 1 root root 7482378 7月 31 10:37 testdisk-7.2-WIP.linux26-x86_64.tar.bz2
117 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.1.log
120 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.4.log
119 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.3.log
118 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.2.log
123 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.7.log
122 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.6.log
121 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.5.log
126 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.log
125 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.9.log
124 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.8.log
127 -rw-r--r--. 1 root root 26664 7月 31 10:37 xfs_undelete-master.zip
./iamela:
总用量 0
./abc:
总用量 3788
75 -rw-------. 1 root root 27469 7月 31 10:37 messages
76 -rw-r--r--. 1 root root 35149 7月 31 10:37 LICENSE
78 -rw-r--r--. 1 root root 150 7月 31 10:37 shell.nix
77 -rw-r--r--. 1 root root 12538 7月 31 10:37 README.md
79 -rw-r--r--. 1 root root 2 7月 31 10:37 1.txt
80 -rw-r--r--. 1 root root 2 7月 31 10:37 2.txt
81 -rw-r--r--. 1 root root 2 7月 31 10:37 3.txt
82 -rw-r--r--. 1 root root 3 7月 31 10:37 4.txt
83 -rw-r--r--. 1 root root 2 7月 31 10:37 5.txt
84 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.1.log
86 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.3.log
85 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.2.log
87 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.4.log
88 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.5.log
89 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.6.log
91 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.8.log
90 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.7.log
93 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.log
92 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.9.log
94 -rw-------. 1 root root 271793 7月 31 10:37 messages-20220410
95 -rw-------. 1 root root 628163 7月 31 10:37 messages-20220421
96 -rw-------. 1 root root 408352 7月 31 10:37 messages-20220424
97 -rw-------. 1 root root 674055 7月 31 10:37 messages-20220501
98 -rw-r--r--. 1 root root 1739411 7月 31 10:37 report.xml
./bcd:
总用量 138972
524417 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.1.log
524418 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.2.log
524420 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.4.log
524419 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.3.log
524421 -rw-r--r--. 1 root root 1774599 7月 31 10:37 log.tar.gz
524422 -rw-r--r--. 1 root root 1170791 7月 31 10:37 log.tar.bz
524423 -rw-r--r--. 1 root root 69068800 7月 31 10:37 lib.tar
524424 -rw-r--r--. 1 root root 26664 7月 31 10:37 abc.zip
524425 -rw-r--r--. 1 root root 1170791 7月 31 10:37 log1.tar.bz
524426 -rw-r--r--. 1 root root 69068800 7月 31 10:37 lib1.tar
./cef:
总用量 44
1069185 -rw-r--r--. 1 root root 57 7月 31 10:37 ld
1069187 -rw-r--r--. 1 root root 689 7月 31 10:37 mta
1069186 -rw-r--r--. 1 root root 101 7月 31 10:37 libnssckbi.so.x86_64
1069190 ----r-xr-x. 1 root root 32 7月 31 10:37 secret_key
1069189 -rw-r--r--. 1 root root 68 7月 31 10:37 NetworkManager.state
1069188 -rw-r--r--. 1 root root 939 7月 31 10:37 NetworkManager-intern.conf
1069191 -rw-r--r--. 1 root root 61 7月 31 10:37 timestamps
1069193 -rw-r--r--. 1 root root 312 7月 31 10:37 a0241666-9184-4733-814d-7bba844a10ae.InvIndex
1069192 -rw-r--r--. 1 root root 5080 7月 31 10:37 8fee3326-1637-4113-8fd5-70819d7ddb4d.StObj
1069194 -rw-r--r--. 1 root root 576 7月 31 10:37 fstab
./pgarch:
总用量 138972
1732705 -rw-r--r--. 1 root root 26664 7月 31 10:37 abc.zip
1732706 -rw-r--r--. 1 root root 69068800 7月 31 10:37 lib1.tar
1732707 -rw-r--r--. 1 root root 69068800 7月 31 10:37 lib.tar
1732708 -rw-r--r--. 1 root root 1170791 7月 31 10:37 log1.tar.bz
1732709 -rw-r--r--. 1 root root 1170791 7月 31 10:37 log.tar.bz
1732710 -rw-r--r--. 1 root root 1774599 7月 31 10:37 log.tar.gz
1732711 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.1.log
1732713 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.3.log
1732712 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.2.log
1732714 -rw-r--r--. 1 root root 734 7月 31 10:37 vmware-network.4.log
——————————————————situation two——————————————————
***@***.*** tmp]# cat lsinfo.txt
.:
总用量 1583736
67 -rw-r--r-- 1 root root 6 7月 21 22:28 123.txt
102 drwxr-xr-x 2 root root 4096 7月 21 22:28 abc
68 -rw-r--r-- 1 root root 194924 7月 21 22:28 amba10.tar.bz
69 -rw-r--r-- 1 root root 194924 7月 21 22:28 amba10.tar.gz
70 -rw-r--r-- 1 root root 195489 7月 21 22:28 amba11.tar.bz
71 -rw-r--r-- 1 root root 195489 7月 21 22:28 amba11.tar.gz
72 -rw-r--r-- 1 root root 194648 7月 21 22:28 amba12.tar.bz
73 -rw-r--r-- 1 root root 194648 7月 21 22:28 amba12.tar.gz
74 -rw-r--r-- 1 root root 194648 7月 21 22:28 amba13.tar.bz
75 -rw-r--r-- 1 root root 99497 7月 21 22:28 amba14.tar.bz
76 -rw-r--r-- 1 root root 99111 7月 21 22:28 amba15.tar.bz
77 -rw-r--r-- 1 root root 99658 7月 21 22:28 amba16.tar.bz
78 -rw-r--r-- 1 root root 70427 7月 21 22:28 amba17.tar.bz
79 -rw-r--r-- 1 root root 41330 7月 21 22:28 amba18.tar.bz
80 -rw-r--r-- 1 root root 41400 7月 21 22:28 amba19.tar.bz
81 -rw-r--r-- 1 root root 194754 7月 21 22:28 amba1.tar.bz
82 -rw-r--r-- 1 root root 194754 7月 21 22:28 amba1.tar.gz
83 -rw-r--r-- 1 root root 9999701 7月 21 22:28 ambari-alerts.log.1
84 -rw-r--r-- 1 root root 9999516 7月 21 22:28 ambari-alerts.log.10
85 -rw-r--r-- 1 root root 9999701 7月 21 22:28 ambari-alerts.log.11
86 -rw-r--r-- 1 root root 9999746 7月 21 22:28 ambari-alerts.log.12
87 -rw-r--r-- 1 root root 9999942 7月 21 22:28 ambari-alerts.log.13
88 -rw-r--r-- 1 root root 9999988 7月 21 22:28 ambari-alerts.log.14
89 -rw-r--r-- 1 root root 9999628 7月 21 22:28 ambari-alerts.log.15
90 -rw-r--r-- 1 root root 9999731 7月 21 22:28 ambari-alerts.log.16
91 -rw-r--r-- 1 root root 9999785 7月 21 22:28 ambari-alerts.log.17
92 -rw-r--r-- 1 root root 9999643 7月 21 22:28 ambari-alerts.log.18
93 -rw-r--r-- 1 root root 9999498 7月 21 22:28 ambari-alerts.log.19
94 -rw------- 1 root root 1157 7月 21 22:28 anaconda-ks.cfg
8388672 drwxr-xr-x 2 root root 118 7月 21 22:28 bcd
95 -rw-r--r-- 1 root root 112 7月 21 22:28 loop-test.sh
96 -rw------- 1 root root 28499 7月 21 22:28 messages
97 -rw-r--r-- 1 root root 14473295 7月 21 22:28 osw.tar.gz
98 -rw-r--r-- 1 root root 1290229760 7月 21 22:28 recup_dir.1.tar
99 -rw-r--r-- 1 root root 7482378 7月 21 22:28 testdisk-7.2-WIP.linux26-x86_64.tar.bz2
100 -rw-r--r-- 1 root root 197213784 7月 21 22:28 var.tar.gz
101 -rw-r--r-- 1 root root 26664 7月 21 22:28 xfs_undelete-master.zip
./abc:
总用量 3788
103 -rw------- 1 root root 27469 7月 21 22:28 messages
104 -rw-r--r-- 1 root root 35149 7月 21 22:28 LICENSE
105 -rw-r--r-- 1 root root 12538 7月 21 22:28 README.md
106 -rw-r--r-- 1 root root 150 7月 21 22:28 shell.nix
107 -rw-r--r-- 1 root root 2 7月 21 22:28 1.txt
109 -rw-r--r-- 1 root root 2 7月 21 22:28 3.txt
108 -rw-r--r-- 1 root root 2 7月 21 22:28 2.txt
111 -rw-r--r-- 1 root root 2 7月 21 22:28 5.txt
110 -rw-r--r-- 1 root root 3 7月 21 22:28 4.txt
112 -rw-r--r-- 1 root root 1739411 7月 21 22:28 report.xml
113 -rw-r--r-- 1 root root 734 7月 21 22:28 vmware-network.1.log
116 -rw-r--r-- 1 root root 734 7月 21 22:28 vmware-network.4.log
115 -rw-r--r-- 1 root root 734 7月 21 22:28 vmware-network.3.log
114 -rw-r--r-- 1 root root 734 7月 21 22:28 vmware-network.2.log
120 -rw-r--r-- 1 root root 734 7月 21 22:28 vmware-network.8.log
119 -rw-r--r-- 1 root root 734 7月 21 22:28 vmware-network.7.log
118 -rw-r--r-- 1 root root 734 7月 21 22:28 vmware-network.6.log
117 -rw-r--r-- 1 root root 734 7月 21 22:28 vmware-network.5.log
121 -rw-r--r-- 1 root root 734 7月 21 22:28 vmware-network.9.log
122 -rw-r--r-- 1 root root 734 7月 21 22:28 vmware-network.log
123 -rw------- 1 root root 271793 7月 21 22:28 messages-20220410
124 -rw------- 1 root root 628163 7月 21 22:28 messages-20220421
125 -rw------- 1 root root 408352 7月 21 22:28 messages-20220424
126 -rw------- 1 root root 674055 7月 21 22:28 messages-20220501
./bcd:
总用量 16
8388674 -rw-r--r-- 1 root root 734 7月 21 22:28 vmware-network.2.log
8388673 -rw-r--r-- 1 root root 734 7月 21 22:28 vmware-network.1.log
8388676 -rw-r--r-- 1 root root 734 7月 21 22:28 vmware-network.4.log
8388675 -rw-r--r-- 1 root root 734 7月 21 22:28 vmware-network.3.log
In the tests of the above two cases, only files with small and continuous inode sequence numbers can be recovered (such as inode67-inode127). Even if -s is used to specify inode sequence numbers, inode files with large sequence numbers cannot be recovered. The recovery command is/ xfs_ Undelete /dev/vgxx/lvxx has no parameters. Please also check whether this problem has occurred and what solutions are available. Thanks, best regards
该邮件从移动设备发送
…------------------ 原始邮件 ------------------
发件人: "ianka/xfs_undelete" ***@***.***>;
发送时间: 2022年7月29日(星期五) 晚上8:55
***@***.***>;
***@***.******@***.***>;
主题: Re: [ianka/xfs_undelete] Restore file with big inode number fail (Issue #32)
Could you describe the problem more in detail?
It's perfectly normal that inode numbers aren't consecutive. Xfs_undelete does not count those numbers up itself. Instead, it walks the inode tree and takes the inode numbers as identifiers only. If you use the -s option, you have to specify an existing inode number. As the tool still walks the tree from the very beginning but does not try to recover anything until that exact inode number specified is found.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
ianka commented
Xfs_undelete does not care about directories. The inode tree is a separate structure.
You don't need the -s option for those tests. It's meant to pick up an interrupted recovery at some existing inode number that had been printed during the interrupted run. So you can recover in multiple batches e.g. if your output directory is on a rather small USB stick. If you point -s to an inode number, it won't start the inode tree walk at that point —that's simply not possible— but walk the whole tree and simply not recover any files before that one inode with the number specified with -s has been passed during the walk.
The inode tree is always walked in its entirety. (Unless you interrupt the recovery run.)
I understood that in your test environment, some files could be recovered, and those tend to have small inode numbers, and their inode numbers tend to be consecutive.
That's unfortunately not enough information to look for a specific bug. Do you have more clues for me?
zzwwcc88 commented
What information can I collect to help you analyze this problem？
message，xfs_info,and what?
该邮件从移动设备发送
…------------------ 原始邮件 ------------------
发件人: "ianka/xfs_undelete" ***@***.***>;
发送时间: 2022年8月3日(星期三) 晚上9:14
***@***.***>;
***@***.******@***.***>;
主题: Re: [ianka/xfs_undelete] Restore file with big inode number fail (Issue #32)
Xfs_undelete does not care about directories. The inode tree is a separate structure.
You don't need the -s option for those tests. It's meant to pick up an interrupted recovery at some existing inode number that had been printed during the interrupted run. So you can recover in multiple batches e.g. if your output directory is on a rather small USB stick. If you point -s to an inode number, it won't start the inode tree walk at that point —that's simply not possible— but walk the whole tree and simply not recover any files before that one inode with the number specified with -s has been passed during the walk.
The inode tree is always walked in its entirety. (Unless you interrupt the recovery run.)
I understood that in your test environment, some files could be recovered, and those tend to have small inode numbers, and their inode numbers tend to be consecutive.
That's unfortunately not enough information to look for a specific bug. Do you have more clues for me?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
ianka commented
Unfortunately, I have been unable to find a solution to your problem. Sorry.
I'm closing this issue. Feel free to reopen if you have new information.