ext4의 디렉토리 당 최대 파일

모든 파일이 md5 합계와 같은 파일 이름으로 저장되는 파일 저장소가 포함 된 응용 프로그램을 관리합니다. 모든 파일은 하나의 디렉토리에 저장됩니다. 현재 수천 개가 있지만 곧 서버에 수백만 개의 파일이 있어야합니다. 현재 서버는 ext4 파일 시스템에서 Ubuntu 11.10을 실행하고 있습니다.

누군가는 디렉토리에 많은 파일을 넣는 것이 현명하지 않다고 말했습니다. 이로 인해 조회 시간과 신뢰성이 크게 증가 할 것입니다 (단일 디렉토리가 가리킬 수있는 최대 파일에 대한 이야기가있어 큰 링크 된 목록이 생성됩니다). 대신 그는 파일 이름의 하위 문자열과 같은 하위 디렉토리를 만들 것을 제안했습니다. 그러나 이것은 내 응용 프로그램의 일부 항목을 훨씬 더 번거롭게합니다.

이것이 사실입니까, 아니면 최신 파일 시스템 (예 : ext4)이이를 처리하고 자연스럽게 확장 할 수있는보다 효율적인 방법이 있습니까? Wikipedia 에는 파일 시스템에 대한 세부 정보가 있지만 실제로 디렉토리 당 최대 파일 수 또는 조회 시간에 대해서는 언급하지 않습니다.

ext3나중에 파일 시스템을 지원 해시 된 B 트리 디렉토리 색인. 이름으로 추가, 삭제 및 액세스하는 작업 만 수행하면 확장 성이 매우 뛰어납니다. 그러나 여전히 디렉토리를 분해하는 것이 좋습니다. 그렇지 않으면 디렉토리에 항목이 너무 많으면 터질 수있는 디렉토리에서 다른 작업을 수행 하는 도구 ( updatedb,, ls등)에 위험한 booby trap을 만듭니다 du.

문제의 핵심은 원하는 하나의 파일에 대한 디렉토리 inode를 파는 것입니다. 일부 파일 시스템은 다른 파일 시스템보다이 작업을 더 잘 수행합니다. 수십억에 어떤 규모의 가까운,하지만 당신 만이있는 경우 ... 20K 파일 로 받고 해당 파일 것은 현저하게 빠르다. 또한 파일 수가 많으면 특정 도구에 문제가 생겨 백업 / 복원이 훨씬 더 어려워 질 수 있습니다.

그것이 일어날 때 나는 우리 자신의 개발 (md5sum과 파일 이름, 스케일링)에서 똑같은 문제에 부딪쳤다. 개발자에게 권장하는 것은 문자열을 조각으로 자르는 것입니다. 그들은 4 그룹으로 갔지만 파일 시스템에서는 많은 사람들이 성능 측면에서 문제가 될 수 있다고 생각 했으므로 처음 6 개의 트리플 렛에 대해 3 그룹으로 나누고 나머지는 터미널 디렉토리의 파일 이름

4 인 4976/d70b/180c/6142/c617/d0c8/9d0b/bd2b.txt
그룹 : 3 인 그룹497/6d7/0b1/80c/614/2c6/17d0c89d0bbd2b.txt

이것은 디렉토리 크기를 작게 유지할 수 있다는 장점이 있으며 MD5sum은 무작위이기 때문에 균형 잡힌 디렉토리 트리를 만듭니다. 마지막 디렉토리는 몇 개 이상의 파일을 얻지 못할 것입니다. 그리고 우리 코드로 작업하기가 어렵지 않았습니다. 우리는 수백만 개의 파일 프로젝트로 작업하므로 스케일링이 매우 중요했습니다.

최신 파일 시스템은 매우 큰 디렉토리, 심지어 수백만 개의 파일까지 매우 잘 처리합니다. 그러나 기존 도구는 그렇지 않습니다. 예를 들어, "ls"로 이러한 큰 디렉토리를 나열하면 일반적으로 전체 디렉토리를 읽고 정렬하기 때문에 시간이 오래 걸립니다 (정렬을 피하기 위해 ls -f를 사용할 수는 있음). 모든 것을 읽을 때까지 파일 표시를 시작하지 않습니다. 이름을 분할하면 일부 경우에 도움이되지만 전부는 아닙니다 (예 : rsync 복제는 여전히 전체 이름 트리를 수집해야 할 수 있음).

대신 SQL 데이터베이스를 사용하는 것이 좋습니다. 이것은 아마도 응용 프로그램에서 감지 된 약점을 강점으로 변형시킬 것입니다.