단일 디렉토리에 몇 개의 파일을 보관해야합니까? 그렇다면 디렉토리에있는 파일 수가 너무 많고 파일이 너무 많으면 어떤 영향이 있습니까? (이것은 Linux 서버에 있습니다.)

배경 : 사진 앨범 웹 사이트가 있으며 업로드 된 모든 이미지의 이름이 8 진수 ID (예 : a58f375c.jpg)로 바뀝니다. 이는 파일 이름 충돌을 피하기위한 것입니다 (예 : “IMG0001.JPG”파일이 많이 업로드 된 경우). 원본 파일 이름과 유용한 메타 데이터는 데이터베이스에 저장됩니다. 지금은 images 디렉토리에 약 1500 개의 파일이 있습니다. 이렇게하면 FTP 또는 SSH 클라이언트를 통해 디렉토리에 파일을 나열하는 데 몇 초가 걸립니다. 그러나 그것이 다른 효과가 있다는 것을 알 수 없습니다. 특히 이미지 파일이 사용자에게 얼마나 빨리 제공되는지에 영향을 미치지 않는 것 같습니다.

16 개의 하위 디렉토리 (0-9 및 af)를 만들어 이미지 수를 줄이는 것에 대해 생각했습니다. 그런 다음 파일 이름의 첫 번째 16 진수가 무엇인지에 따라 이미지를 하위 디렉토리로 이동합니다. 그러나 때때로 FTP / SSH를 통한 디렉토리 목록을 제외하고 그렇게 할 이유가 있는지 확실하지 않습니다.

답변

FAT32 :

최대 파일 수 : 268,173,300
디렉토리 당 최대 파일 수 : 2 ⁽¹⁶⁾ – 1 (65,535)
최대 파일 크기 : LFS 없이 2 GiB-1 , 4 GiB-1

NTFS :

최대 파일 수 : 2 ⁽³²⁾ – 1 (4,294,967,295)
최대 파일 크기
- 구현 : 2 ⁴⁴ – 2 ⁶ 바이트 (16 TiB 크기 – 64 킬로바이트)
- 이론 2 ⁶⁴ – 2 ⁶ 바이트 (EIB 16 – 64 킬로바이트)
최대 볼륨 크기
- 구현 : 2 ³² – 1 개 클러스터 (256 TiB 크기 – 64 킬로바이트)
- 이론 2 개 ⁶⁴ – 1 클러스터 (1 YiB – 64 킬로바이트)

ext2 :

최대 파일 수 : 10 ¹⁸
디렉토리 당 최대 파일 수 : ~ 1.3 × 10 ²⁰ (1 만 개 이상의 성능 문제)
최대 파일 크기
- 16GiB (1KiB의 블록 크기)
- 256GiB (블록 크기 2KiB)
- 2TiB (4 KiB의 블록 크기)
- 2TiB (8 KiB의 블록 크기)
최대 볼륨 크기
- 4TiB (1 KiB의 블록 크기)
- 8TiB (2 KiB의 블록 크기)
- 16TiB (4 KiB의 블록 크기)
- 32TiB (8 KiB의 블록 크기)

ext3 :

최대 파일 수 : min (volumeSize / 2 ¹³ , numberOfBlocks)
최대 파일 크기 : ext2와 동일
최대 볼륨 크기 : ext2와 동일

ext4 :

최대 파일 수 : 2 ⁽³²⁾ – 1 (4,294,967,295)
디렉토리 당 최대 파일 수 : 무제한
최대 파일 크기 : 2 ⁽⁴⁴⁾ – 1 바이트 (16 TiB 크기 – 1)
최대 볼륨 크기 : 2 ⁽⁴⁸⁾ – 1 바이트 (256 TiB 크기 – 1)

답변

단일 ext3 디렉토리에 8 백만 개가 넘는 파일이 있습니다. libc에 readdir()의해 사용되는 find, ls다른 방법의 가장 큰 디렉토리 목록이 글에서 논의.

그 이유 ls및 find이 경우 느린 것은 즉 readdir()단지 속도가 느린 디스크에 많은 많은 디렉토리를 나열하는 읽기가 필요합니다, 한 번에 디렉토리 항목의 32K를 읽습니다. 이 속도 문제에 대한 해결책이 있습니다. 나는 그것에 대해 꽤 자세한 기사를 썼습니다 : http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- ls /

핵심 요소는 다음과 같습니다. getdents()직접 사용 -libc를 기반으로하는 것이 아니라 http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.htmlreaddir() 사용하여 버퍼를 지정할 수 있습니다. 디스크에서 디렉토리 항목을 읽을 때 크기.

답변

88,914 개의 파일이있는 디렉토리가 있습니다. 자신과 마찬가지로 이것은 축소판 그림을 저장하고 Linux 서버에 사용됩니다.

FTP 또는 PHP 기능을 통한 나열된 파일은 느리지 만 파일을 표시 할 때 성능이 저하됩니다. 예 : www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg의 대기 시간은 200-400ms입니다. 다른 사이트와 비교할 때 디렉토리에 약 100 개의 파일이 있는데 ~ 40ms 대기 후 이미지가 표시됩니다.

대부분의 사람들이 디렉토리 검색 기능이 수행되는 방식을 작성 했으므로이 대답을주었습니다.이 폴더는 엄지 폴더에서 사용하지 않고 정적으로 파일을 표시하지만 파일을 실제로 사용할 수있는 방법에 관심이 있습니다. .

답변

Linux 서버에서 사용중인 특정 파일 시스템에 따라 다릅니다. 현재 기본값은 dir_index를 사용하는 ext3이며 큰 디렉토리를 매우 빠르게 검색합니다.

따라서 이미 언급 한 것 외에는 속도가 문제가되지 않아야합니다. 즉, 리스팅이 더 오래 걸립니다.

한 디렉토리에있는 총 파일 수에는 제한이 있습니다. 32000 파일까지 확실히 작동하는 것을 기억합니다.

답변

Linux에서 파일이 너무 많은 디렉토리가 있으면 셸에서 와일드 카드를 확장하지 못할 수 있습니다. Linux에서 호스팅되는 사진 앨범에이 문제가 있습니다. 모든 크기 조정 된 이미지를 단일 디렉토리에 저장합니다. 파일 시스템은 많은 파일을 처리 할 수 있지만 쉘은 처리 할 수 없습니다. 예:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

또는

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

답변

지금 비슷한 문제를 겪고 있습니다. 우리는 계층 구조의 디렉토리 구조를 가지고 있으며 이미지 ID를 파일 이름으로 사용합니다. 예를 들어, 함께 화상을 id=1234567배치한다

..../45/67/1234567_<...>.jpg

마지막 4 자리 숫자를 사용하여 파일의 위치를 결정합니다.

수천 개의 이미지로 1 단계 계층 구조를 사용할 수 있습니다. 우리의 sysadmin은 효율성 / 백업 / 그가 생각한 다른 이유에 대해 주어진 디렉토리 (ext3)에 수천 개 이상의 파일을 제안했습니다.

답변

그만한 가치가 있기 위해 방금 디렉토리에 디렉토리를 만들었습니다. ext4 파일 시스템에 1,000,000 개의 파일이 다음 웹 서버를 통해 해당 파일에 무작위로 액세스했습니다. 파일이 10 개 이상인 사람들에게 액세스하는 것에 대해서는 아무런 프리미엄이 없었습니다.

이것은 몇 년 전에 이것을 한 경험과 근본적으로 다릅니다 ntfs.