>

2 단계 해시 디렉토리 구조에 약 백만 개의 파일이 중복 제거 된 스토리지가 있습니다. 파일 시스템은 자기 디스크의 ext4 파티션입니다. 파일의 경로는 다음과 같이 MD5 해시로 계산됩니다.

e93ac67def11bbef905a7519efbe3aa7 -> e9/3a/e93ac67def11bbef905a7519efbe3aa7

파일 목록을 순차적으로 처리 할 때 (별도의 데이터베이스에 저장된 메타 데이터로 선택) 말 그대로 탐색에서 생성 된 노이즈 (해시 된 디렉토리 레이아웃에 의해 "임의 화 된")를들을 수 있습니다.

실제 질문은 다음과 같습니다.확장 가능한 작은 파일 목록을 ext4 파티션에 저장 한 경우 탐색 최적화 방식으로 처리 할 수있는 (일반적인) 방법이 있습니까? 자기 디스크에 (리눅스 사용을 암시하는 것)?

이러한 최적화는 물론 작은 파일이 충분히 공유 된 경우에만 유용합니다. 따라서 파일의 크기 분포에 너무 신경 쓰지 마십시오. 일반성을 잃지 않고 실제로는 각 목록에 작은 파일 만 있다고 가정 할 수 있습니다.

잠재적 인 해결책으로, 파일을 실제 디스크 위치 나 전체 목록을 처리하는 데 필요한 탐색 작업의 총량과 길이와 관련 될 수있는 다른 (휴리스틱) 기준으로 파일을 정렬하려고했습니다.

파일 형식 및 사용 사례에 대한 참고 사항 (필요한 경우)

파일은 여러 데스크톱 시스템의 중복 제거 된 백업입니다. 따라서 일반적으로 개인용 컴퓨터에서 찾은 파일은 파티션에 포함됩니다. 그러나 처리는데이터베이스를 통해 선택된 관심 분야의 일부에만 영향을 미칩니다.

다음은 예시를위한 유스 케이스입니다 (목록은 전체가 아님) :

  • 미디어 파일 (ID3, EXIF ​​등)에서 메타 데이터 추출 (파일은 크지 만 파일의 일부만 읽으므로 효과적으로 작게 됨)
  • 분류기로 처리하기 위해 모든 JPEG 이미지의 작은 버전을 계산
  • 압축 및/또는 암호화를 위해 저장소의 일부를 읽는 경우 (예 : tar 아카이브에 X보다 작고 Y보다 작은 모든 파일 배치)
  • 모든 Word 문서의 헤드 라인 추출
  • 데이터 무결성을 확인하기 위해 모든 MD5 해시를 다시 계산
<시간>

이 질문을 연구하는 동안 나는 FIBMAP 에 대해 배웠습니다.   ioctl  명령 (예 : 파일이 이동하지 않고 결과가 메타 데이터와 함께 저장 될 수 있기 때문에 여기에서 ) 유용합니다. 그러나 파일의 inode의 위치가 내용의 위치와 다소 관련이있는 경우 정렬 기준으로 만 작동한다고 가정합니다.ext4에 맞습니까?

<시간>

*) 즉, 각 파일을 열고 파일의 헤드 (임의 바이트 수) 또는 전체 파일을 메모리로 읽는 것입니다.


  • 답변 # 1

    파일 (특히, 충분히 큰 경우)은 디스크의 여러 블록에 흩어져 있습니다 (예 : ext2 wikipage의 그림과 같이 세부 사항이 다르더라도 여전히 ext4와 관련이 있습니다). 더 중요한 것은 페이지 캐시에있을 수 있으므로 디스크 액세스가 필요하지 않습니다. 따라서 "디스크 위치별로 파일 목록 정렬"은 일반적으로 의미가 없습니다.

    대신 이러한 파일에 액세스하는 코드를 개선하는 것이 좋습니다. posix_fadvise (2) 및 readahead (2)와 같은 시스템 호출을 살펴보십시오.

    파일이 실제로 작 으면 (수백 바이트 만) sqlite 또는 PostGreSQL과 같은 실제 RDBMS 또는 gdbm ...과 같은 다른 것을 사용하는 것이 더 빠를 수 있습니다.

    BTW, RAM을 더 추가하면 페이지 캐시 크기가 커질 수 있으므로 전반적인 경험이 향상됩니다. HDD를 일부 SSD로 교체하면 도움이됩니다.

    (linuxatemyram 참고)

    와이즈 비즈

    실제로는 불가능합니다. 파일 시스템 조각화는 실제로는 ext4에서 중요하지 않습니다. 물론 모든 파일 시스템 (예 : tar 또는 cpio 아카이브)을 백업하고 순차적으로 복원 (

    Is it possible to sort a list of files to optimize read speed / minimize seek times?

    로 새로운 파일 시스템을 만든 후) )는 조각화를 약간 낮출 수 있지만 그렇게 많지는 않습니다.

    파일 시스템 설정 (블록 크기, 클러스터 크기 등을 최적화 할 수 있습니다 (예 : mke2fs (8)에 대한 다양한 인수). ext4 (5)도 참조하십시오.

    와이즈 비즈

    목록이 너무 길지 않은 경우 (그렇지 않으면 각각 수백 개의 파일 단위로 분할) 각 파일을 열고 (2) 각 파일 설명자에서 readahead (2)를 사용한 다음 닫습니다 (2 ) 그것. 이것은 어떻게 든 페이지 캐시를 미리 채울 것입니다 (그리고 커널은필요한 IO 작업을 재정렬 할 수 있습니다).

    (귀하의 사례가 얼마나 효과적인지 모르겠습니다. 벤치마킹해야합니다)

    문제에 대한 소프트웨어 솔루션이 확실하지 않습니다. 문제가 IO 바운드 일 가능성이 있으므로 병목 현상이 하드웨어 일 수 있습니다.

    현재 대부분의 하드 디스크에서 CHS 주소 지정 (커널이 사용)은 디스크 컨트롤러가 처리하는 일부 "논리적"주소 지정이며 더 이상 물리적 지오메트리와 관련이 없습니다. LBA, TCQ, NCQ에 대해 읽어보십시오 (오늘날 커널은 하드 디스크 헤드의 실제 기계적 움직임에직접영향을 미치지 않습니다). I/O 스케줄링은 대부분 하드 디스크 자체에서 발생합니다 (커널에서는 그다지 중요하지 않습니다).

    mkfs

관련 자료

  • 이전 c# - Entity Framework, 임의의 엔티티를 매개 변수로 사용하는 메소드 (코드를보다 일반화하는 방법)
  • 다음 javascript - cloud function에서 cloud dataflow 파이프 라인 트리거링 - 기능 시간 초과