답변:
"debugfs"도구를 사용하여 명령 행 또는 interactivley에서 파일 정보를 볼 수 있습니다. 어느 쪽이든 사용하십시오 :
# debugfs /dev/<spartition>
# stat /path/to/file
또는
# debugfs -R "stat /path/to/file" /dev/<partition>
예를 들면 다음과 같습니다.
# debugfs -R "stat /etc/passwd" /dev/sda5
Inode: 435914 Type: regular Mode: 0644 Flags: 0x0
Generation: 979004472 Version: 0x00000000
User: 0 Group: 0 Size: 1577
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4a2d6f78 -- Mon Jun 8 23:07:20 2009
atime: 0x4a2d6f79 -- Mon Jun 8 23:07:21 2009
mtime: 0x4a2d6f78 -- Mon Jun 8 23:07:20 2009
Size of extra inode fields: 4
BLOCKS:
(0):1767438
TOTAL: 1
path/to/file모든 경우에 왜 작동하지 않아야 합니까? 내가 혼동하는 것은 debugfs ..... /dev/fs_blockdev내 이해력 을 통해 고려할 파일 시스템이 하나 뿐이며이 시스템 내의 모든 파일은 경로 또는 타이어 아이 노드를 통해 액세스 할 수 있다는 것입니다. 무엇을 표현하고 싶습니까?
debugfs -R "stat /home/myuser/foo.txt" /dev/sda5된 경우 오류가 발생합니다. 그러나 debugfs -R "stat /path/on/rootfs" /dev/sda3작업을 호출 합니다.
sudo. 그렇지 않으면 도움이되지 않는 메시지가 표시됩니다.
debugfs답변 에서처럼 파티션에서 읽을 필요없이 블록 목록을 얻는 간단한 방법 은 FIBMAPioctl 을 사용하는 것 입니다. 나는 어떤 명령을해야할지 모르겠지만 작성하는 것은 매우 간단합니다. 빠른 Google 검색 으로 FIBMAP use의 예를 들었습니다 . 한 가지 장점은 bmapext3뿐만 아니라 작업 을 지원하는 모든 파일 시스템에서 작동한다는 것입니다 .
FIEMAPioctl 이 더 새롭고 더 효율적인 대안으로, 익스텐트에 대한 자세한 정보를 반환 할 수 있습니다 (ext4에 유용).
hdparm --fibmap /path/to/filename
zfs에서는 작동하지 않지만 ext4, btrfs, (v) fat 등에서는 작동합니다.
--fibmap사용될 때, 이것은 주어진 유일한 플래그 여야합니다. 매개 변수로 파일 경로가 필요하며 해당 파일이 차지하는 장치 범위 (섹터 범위) 목록을 디스크에서 인쇄합니다. 섹터 번호들은 물리적 장치 (섹터 0에서 참조 절대 LBA 참조로 주어진다 하지 파티션 또는 파일 시스템). 그런 다음이 정보는 더 큰 파일의 조각화 정도를 검사하거나 결함 주입 테스트 절차 중에 의도적으로 손상 될 적절한 섹터를 결정하는 등의 다양한 목적으로 사용될 수 있습니다.
e2fsck -b 32768 / dev / hda1 나는 이것을 시도 할 수 있다고 느끼거나 같은 u에서 더 많은 docx를 찾고 있다면 다음을 확인할 수 있다고 느낀다.
http://www.linux-tutorial.info/modules.php?name=MContent&pageid=97
File not found by ext2_lookup. 따라서 stat의 인수에 inode 표기법을 사용하는 것이 좋습니다. 사용은ls -i'<>'대신에 / 경로 /로 / 파일에서 해당 번호와 debugfs의있는 invoke 후, 파일의 inode 번호를 얻을 수 있습니다. 예를 들면 :# debugfs -R "stat <1234567>" /dev/sda2