| 1 |
find / -xdev -inum <#> |
| 2 |
|
| 3 |
If you know it is in a directory more specific than /, replace / with |
| 4 |
that directory. inodes are only meaningful to ext2/3/4, but you can |
| 5 |
use the fs tools to find out where it is on disk. |
| 6 |
|
| 7 |
On Thu, Dec 18, 2014 at 3:14 PM, Poison BL. <poisonbl@×××××.com> wrote: |
| 8 |
> On Thu, Dec 18, 2014 at 3:24 PM, <meino.cramer@×××.de> wrote: |
| 9 |
>> Hi, |
| 10 |
>> |
| 11 |
>> with |
| 12 |
>> |
| 13 |
>> sysctl vm.block_dump=1 |
| 14 |
>> |
| 15 |
>> one can enable the logging of IO to the harddisk/flashmem/... |
| 16 |
>> into dmesg. |
| 17 |
>> The logs report the block number of the file in question... |
| 18 |
>> but not the filename itsself. |
| 19 |
>> |
| 20 |
>> Is there any other way as examine each single file of the |
| 21 |
>> filesystem to find the file to which a certain block number |
| 22 |
>> is assigned? |
| 23 |
>> |
| 24 |
>> Thank you very mcuh for any help! |
| 25 |
>> Best regards, |
| 26 |
>> Meino |
| 27 |
>> |
| 28 |
>> |
| 29 |
>> |
| 30 |
> |
| 31 |
> That depends entirely on the filesystem being used. In the case of |
| 32 |
> ext2/3/4, I believe /sbin/debugfs will do the trick with its icheck |
| 33 |
> command to get the inode, and once you have the inode, you can get the |
| 34 |
> filename via find. What I'm not 100% certain of is whether the block |
| 35 |
> numbers involved map 1:1 with physical sectors, and how that plays |
| 36 |
> with the 512B vs 4KB sectors, etc. With NTFS it's a hair quicker with |
| 37 |
> ntfscluster and ntfsinfo doing the trick fairly trivially (I use a |
| 38 |
> tool centered around that combo to identify files lost when I recover |
| 39 |
> peoples windows drives with ddrescue). |
| 40 |
> |
| 41 |
> -- |
| 42 |
> Poison [BLX] |
| 43 |
> Joshua M. Murphy |
| 44 |
> |
Archives