Linux EXT 4: 블록 그룹을 차지하는 파일을 나열하는 방법은 무엇입니까?

Question

큰 어려움을 겪고 있습니다. 이것e2fsprogs패키지에는 필요한 기본 사항, 특히 debugfs파일 시스템을 탐색하고 블록 그룹 및 파일 할당을 보는 데 사용할 수 있는 기본 사항이 포함되어 있습니다. 다음은 debugfs stats 및 Extent 명령에서 발췌한 내용입니다.

debugfs:   stats
 Group  0: block bitmap at 64, inode bitmap at 80, inode table at 96
           28663 free blocks, 5777 free inodes, 3 used directories, 5777 unused inodes
           [Checksum 0xe713]
 Group  1: block bitmap at 65, inode bitmap at 81, inode table at 596
           0 free blocks, 8000 free inodes, 0 used directories, 8000 unused inodes
           [Inode not init, Checksum 0x9416]
 Group  2: block bitmap at 66, inode bitmap at 82, inode table at 1096
           0 free blocks, 8000 free inodes, 0 used directories, 8000 unused inodes
…
debugfs:  extents bigfile
Level Entries       Logical        Physical Length Flags
 0/ 1   1/  1     0 - 62499 120569           62500
 1/ 1   1/  6     0 - 12287 133120 - 145407  12288 
 1/ 1   2/  6 12288 - 12499 131524 - 131735    212 
 1/ 1   3/  6 12500 - 24575 145408 - 157483  12076 
 1/ 1   4/  6 24576 - 24999 131736 - 132159    424 
 1/ 1   5/  6 25000 - 30719 157484 - 163203   5720 
 1/ 1   6/  6 30720 - 62499 165888 - 197667  31780

이렇게 하면 원하는 정보를 종합할 수 있지만ext4 디스크 레이아웃 로드맵도움이 될 것입니다.

그럴 필요가 없는데 왜 이런 방식으로 파일 시스템을 뒤져보고 싶어하는지 궁금하지 않을 수 없지만, 어쩌면 정말로 알고 싶지 않을 수도 있습니다.

댓글에 답글을 추가하려면:

블록 그룹의 중요한 설계 동기는 측정하려는 검색 페널티를 최소화하는 것입니다. 즉, 파일 시스템은 여유 목록, inode 테이블 및 데이터 블록 메타데이터를 드라이브의 블록 그룹에 배포하므로 헤드가 하나일 때처럼 헤드가 가장자리에서 가장자리로 이동할 필요가 없습니다. FAT 파일 시스템과 동일한 블록 그룹입니다. NTFS가 이전 FAT 스타일인지, 아니면 BSD-FFS 및 그 후속 버전과 같이 더 지능적인지는 알 수 없습니다.

원하는 비교를 수행하는 보다 안정적인 방법은 드라이브 파티셔닝을 이용하는 것입니다. 예를 들어 드라이브를 외부, 중간, 내부 파티션으로 분할한 경우 외부 파티션에서 내부 파티션으로 복사하여 강제로 검색할 수 있습니다. 이를 강제하기 위해 블록 그룹을 사용하려고 하면 파일 시스템은 드라이브 액세스를 로컬로 유지하도록 설계되었기 때문에 사용자의 노력에 "저항"하게 됩니다.

여러 파티션이 있는 경우에도 시스템 전체의 블록 캐시가 장치 드라이버와 함께 작동하여 다음 트릭을 사용하여 먼 위치에 대한 쓰기를 지연할 것으로 예상할 수 있습니다.엘리베이터 알고리즘. 간단히 말해서, 시스템 전반에 걸쳐 측정하려는 정확한 현상을 최소화하도록 설계된 수많은 최적화를 중단하려고 합니다. 또한 드라이브 컨트롤러 전자 장치가 탐색 감소 게임과 관련되어 있으며 그 중 대부분은 완전히 숨겨져 있음을 알 수 있습니다.

원시 장치를 열고 올바른 ioctl을 사용하여 드라이브가 수행하려는 최적화되지 않은 쓰기 작업을 수행하도록 강제할 수 있지만 이러한 실험은 실제 성능과 거의 관련이 없으며 거의 쓸모가 없습니다. 이 문제가 발생하면 하드웨어 사양에서 제조업체의 최대 헤드 탐색 시간을 읽고 테스트를 잊어버릴 수도 있습니다. 아니면 그냥 DOS를 실행할 수도 있습니다.

댓글에 대한 두 번째 답변:

fseek 테스트에서는 블록 캐시가 사용자가 요청한 것보다 더 많이 읽고 다음 비트를 곧 요청할 것으로 예상하기 때문에 헤드 탐색 효과가 나타나지 않을 수 있습니다.

다시 한번 강조하자면, 시스템의 모든 부분은 귀하에게 검색 처벌을 가하려는 귀하의 노력에 대응하도록 설계되었습니다. 이쯤 되면 당신의 관심이 이론인지 실무인지 묻고 싶습니다. 이론적이라면 이미 답을 갖고 있다고 생각합니다. 이것이 가능하다면 정의상 실제 부하를 대표하지 않는 테스트를 설계해야 합니다.

당신은 실제로 어떤 질문에 대한 답을 찾고 있습니까? 새로운 질문을 해주세요. 시간이 너무 깁니다.

Answer 1