디스크에서 파일이 실제로 위치한 위치 (블록 번호)를 어떻게 알 수 있습니까?

10

이것은 모호한 질문입니다. Linux 상자에서 일부 디스크의 성능 테스트를 수행하려고합니다. 동일한 디스크에서 동일한 테스트를 실행하여 일관성이없는 결과가 나타납니다. 디스크의 어느 부분에 액세스하는지에 따라 디스크의 성능이 다르다는 것을 알고 있습니다. 특히 디스크 외부에 대한 읽기 및 쓰기는 데이터 밀도가 거의 일정하고 회전 속도가 일정하기 때문에 디스크 내부에 대한 읽기 및 쓰기보다 처리량이 훨씬 높습니다.

불일치가 처리량의 이러한 기하학 유발 분산으로 인한 것일 수 있는지 확인하고 싶습니다. 기존 도구를 사용하여 디스크에서 파일이있는 위치를 찾을 수 있습니까?

그렇지 않다면 파일 시스템을 우회 (및 파괴)하여 장치 파일 자체를 직접 찾고 읽고 쓸 수있는 것을 쓸 수 있다고 생각하지만 피하지 않기를 바랍니다. 현재 3.0 커널에서 ext4를 사용하고 있습니다 (중요한 경우 Linux Linux).하지만 다른 파일 시스템의 기술에도 관심이 있습니다.

— 릭 코시
소스

1

누가 파일이 한 곳에 있다고 말합니까? 그들이 조각화되면 (일반적으로) 끝날 수 있습니다.

— Sirex

물론. 그러나 그들은 여전히 어딘가에 있습니다 :-) 그리고 특별한 경우, 새로 만든 파일 시스템에 파일을 쓰면 (대부분) 조각화되지 않을 가능성이 큽니다.

— Rick Koshi

당신은 이것을 할 수 없습니다. 얻을 수있는 최선의 방법은 파일의 LBA 블록 번호이며, 지정된 물리적 위치와 반드시 일치하지는 않습니다 (적어도 드라이브가이 매핑을 게시하지 않기 때문에 결정할 수있는 방식이 아님). 예를 들어, 블록 3-5는 연속적으로 번호가 매겨 질 수 있지만 4의 원래 섹터가 물리적으로 손상된 등으로 인해 드라이브의 완전히 다른 위치에 4가 재 할당되었을 수 있습니다. 정보를 얻을 수 없습니다. 드라이브 제조업체가 자세한 주소 사양을 제공 할 의사가없는 경우를 찾고 있습니다.

— Jason C

7

debugfs이것을 위해 사용할 수 있습니다 :

debugfs -R "stat ~/myfile" /dev/hda1

하드 / 파티션 드라이브를 적절히 변경하고 드라이브가 마운트 해제되었는지 확인하십시오. 사용 된 모든 블록이있는 목록이 나타납니다.

BLOCKS:
(0):1643532
TOTAL: 1

— 바트 드 보스
소스

1

고마워요. 그래도 드라이브가 마운트 해제되었는지 확인한 이유를 잘 모르겠습니다. 매뉴얼 페이지에 따르면, debugfs는 기본적으로 읽기 전용 모드로 열리므로이 명령은 활성 파일 시스템에서도 완전히 안전해야합니다. 물론 쿼리 된 파일이 활발하게 변경되면 의심스러운 결과를 제공 할 수 있지만 다른 문제는 발생하지 않습니다. 내가 놓친 것이 있습니까?

— Rick Koshi

아니, 네 말이 맞아 그것은 '최상의 관행'이 아니라 필수입니다. 당신은 활성 파일 시스템에 그 일을하는 경우, 파일 등 변경 될 수 있습니다

— 바트 드 보스

1

LBA 블록 번호는 파일이 디스크의 실제 위치를 알려주지 않습니다. 실제 위치와 LBA에서 요즘 변환은 일반적으로 그것의 말하기 때문에 현대 드라이브의 물리적 구조의 복잡성, 일반적으로 배후 부문의 재 할당 등을 할 수 없습니다 일반적으로 안전한 내기가 디스크 기반 미디어가있는 LBA 절감을 위해 드라이브의 외부를 향하고 있지만 이는 과거에 CHS 주소 지정 시절에 그 레이아웃이 일반적 이었기 때문입니다. 최신 드라이브는 더 이상 실제 CHS 지오메트리를 게시하지 않습니다.

— Jason C

팻 파이 시스템은 어떻습니까?

— dashesy

10

FIBMAP ioctl을 여기 에 예시 된대로 사용하거나 hdparm을 사용하여 사용할 수 있습니다 .

/ $ sudo /sbin/hdparm --fibmap /etc/X11/xorg.conf

/etc/X11/xorg.conf:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0    1579088    1579095          8

— 프랑소와 G
소스

불행히도 stat의 출력은 필요한 정보가 아닙니다. 바이트 및 블록 크기, 아이 노드 번호, 권한 ... 이들 중 어느 것도 파일의 데이터를 포함 하는 블록을 반영하지 않습니다 . 예를 들어, 테스트 파일 (모두 동일한 크기)은 inode 번호 및 액세스 / 수정 시간을 제외하고 모두 정확히 동일한 데이터를 표시합니다.

— Rick Koshi

예, 당신 말이 맞아요, 죄송합니다. 제대로 읽지 않았습니다. 나는 대답을 더 적절하게 바꾸었다.

— Francois G

hdparm은 실제로 필요한 것을 제공하며 debugfs보다 약간 더 읽기 쉬운 형식으로되어 있습니다. 그래도 기본적으로 설치되어 있지 않기 때문에 찾아야했습니다. debugfs는 e2fsprogs (mkfs 및 fsck를 제공하는 동일한 패키지)의 일부이므로 기본적으로 설치됩니다.

— Rick Koshi

LBA는 파일이 드라이브의 실제 위치를 알려주지 않습니다. LBA의 실제 물리적 매핑에 대한 정보를 얻을 수 없습니다.

— Jason C

나는 이것을 지방에서 얻는다 :HDIO_GETGEO failed: Inappropriate ioctl for device

— dashesy

5

이 스레드는 ext4 파일 배치 알고리즘에 대한 통찰력을 제공 할 수 있습니다.

debugfs가 bmap원하는 데이터를 제공하는 것 기능을. 파일에 연속적인 블록을 제공하고 물리적 블록 번호를 얻을 수 있어야합니다.

— 파 웨브 로다 키
소스

1

ext4 파일 배치에 대한 스레드의 포인터에 감사드립니다. 깨달았습니다. :-)

— Rick Koshi

LBA는 파일이 드라이브의 실제 위치를 알려주지 않습니다. LBA의 실제 물리적 매핑에 대한 정보를 얻을 수 없습니다.

— Jason C

2

질문은 다소 오래되었지만 Google에서 이것을 찾는 사람들에게 유용 할 수있는 또 다른 대답이 있습니다 filefrag(Debian에서는 package 안에 있습니다 e2fsprogs).

# filefrag -eX /usr/bin/aptitude
Filesystem type is: ef53
File size of /usr/bin/aptitude is 4261400 (1041 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..     1fa:    15bd805..   15bd9ff:    1fb:            
   1:      1fb..     3f2:    15c6608..   15c67ff:    1f8:    15bda00:
   2:      3f3..     410:    15c8680..   15c869d:     1e:    15c6800: last,eof
/usr/bin/aptitude: 3 extents found

여기에 설명 된 다른 도구에서 지원하지 않는 다른 파일 시스템 (UDF에 사용)에서도 작동한다는 장점이 있습니다.

출력에 표시되는 오프셋은 두 번째 줄에 쓰여진 블록 크기의 배수 (4096)입니다. 파일에 구멍이있을 수 있으므로 (파일 시스템에서 지원하는 경우) 논리적 오프셋은 연속적이지 않을 수 있습니다.

— 지오바니 마스 셀 라니
소스