Apakah penting berapa banyak file yang saya simpan dalam satu direktori? Jika demikian, berapa banyak file dalam direktori yang terlalu banyak, dan apa dampak dari memiliki terlalu banyak file? (Ini di server Linux.)

Latar Belakang: Saya memiliki situs web album foto, dan setiap gambar yang diunggah diganti namanya menjadi id 8-hex-digit (misalnya, a58f375c.jpg). Ini untuk menghindari konflik nama file (jika banyak file "IMG0001.JPG" diunggah, misalnya). Nama file asli dan metadata yang berguna disimpan dalam database. Saat ini, saya memiliki sekitar 1500 file di direktori gambar. Ini membuat daftar file dalam direktori (melalui FTP atau klien SSH) memerlukan waktu beberapa detik. Tetapi saya tidak dapat melihat bahwa itu memiliki efek selain itu. Secara khusus, sepertinya tidak ada dampak pada seberapa cepat file gambar disajikan kepada pengguna.

Saya telah berpikir tentang mengurangi jumlah gambar dengan membuat 16 subdirektori: 0-9 dan af. Lalu saya memindahkan gambar ke subdirektori berdasarkan apa digit hex pertama dari nama file. Tapi saya tidak yakin bahwa ada alasan untuk melakukannya kecuali untuk daftar direktori sesekali melalui FTP / SSH.

FAT32 :

• Jumlah file maksimum: 268.173.300
• Jumlah maksimum file per direktori: 2 ¹⁶  - 1 (65.535)
• Ukuran file maksimum: 2 GiB - 1 tanpa LFS , 4 GiB - 1 dengan

NTFS :

• Jumlah file maksimum: 2 ³²  - 1 (4.294.967.295)
• Ukuran file maksimum
  • Implementasi: 2 ⁴⁴  - 2 ⁶ byte (16 TiB - 64 KiB)
  • Teoritis: 2 ⁶⁴  - 2 ⁶ byte (16 EiB - 64 KiB)
• Ukuran volume maksimum
  • Implementasi: 2 ³²  - 1 cluster (256 TiB - 64 KiB)
  • Teoritis: 2 ⁶⁴  - 1 cluster (1 YiB - 64 KiB)

ext2 :

• Jumlah file maksimum: 10 ¹⁸
• Jumlah maksimum file per direktori: ~ 1,3 × 10 ²⁰ (masalah kinerja lebih dari 10.000)
• Ukuran file maksimum
  • 16 GiB (ukuran blok 1 KiB)
  • 256 GiB (ukuran blok 2 KiB)
  • 2 TiB (ukuran blok 4 KiB)
  • 2 TiB (ukuran blok 8 KiB)
• Ukuran volume maksimum
  • 4 TiB (ukuran blok 1 KiB)
  • 8 TiB (ukuran blok 2 KiB)
  • 16 TiB (ukuran blok 4 KiB)
  • 32 TiB (ukuran blok 8 KiB)

ext3 :

• Jumlah maksimum file: min (volumeUkuran / 2 ¹³ , numberOfBlocks)
• Ukuran file maksimum: sama dengan ext2
• Ukuran volume maksimum: sama dengan ext2

ext4 :

• Jumlah file maksimum: 2 ³²  - 1 (4.294.967.295)
• Jumlah maksimum file per direktori: tidak terbatas
• Ukuran file maksimum: 2 ⁴⁴  - 1 byte (16 TiB - 1)
• Ukuran volume maksimum: 2 ⁴⁸  - 1 byte (256 TiB - 1)

Saya memiliki lebih dari 8 juta file dalam satu direktori ext3. libc readdir()yang digunakan oleh find, lsdan sebagian besar metode lain yang dibahas dalam utas ini untuk daftar direktori besar.

Alasan lsdan findlambat dalam hal ini adalah bahwa readdir()hanya membaca 32K entri direktori pada satu waktu, sehingga pada disk lambat itu akan memerlukan banyak banyak bacaan untuk mendaftar direktori. Ada solusi untuk masalah kecepatan ini. Saya menulis artikel yang cukup rinci tentang hal itu di: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- ls /

Kuncinya adalah: gunakan getdents()langsung - http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html daripada apa pun yang didasarkan pada libc readdir()sehingga Anda dapat menentukan buffer ukuran saat membaca entri direktori dari disk.

Saya memiliki direktori dengan 88.914 file di dalamnya. Seperti diri Anda, ini digunakan untuk menyimpan thumbnail dan pada server Linux.

File yang terdaftar melalui FTP atau fungsi php lambat ya, tetapi ada juga kinerja yang bagus saat menampilkan file. misalnya www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg memiliki waktu tunggu 200-400 ms. Sebagai perbandingan di situs lain yang saya miliki dengan sekitar 100 file dalam direktori gambar ditampilkan setelah hanya menunggu ~ 40 ms.

Saya telah memberikan jawaban ini karena kebanyakan orang baru saja menulis bagaimana fungsi pencarian direktori akan melakukan, yang Anda tidak akan menggunakan pada folder jempol - hanya menampilkan file secara statis, tetapi akan tertarik pada kinerja bagaimana file sebenarnya dapat digunakan .

Tergantung sedikit pada sistem file tertentu yang digunakan di server Linux. Saat ini standarnya adalah ext3 dengan dir_index, yang membuat pencarian direktori besar sangat cepat.

Jadi kecepatan seharusnya tidak menjadi masalah, selain yang sudah Anda catat, karena itu listing akan lebih lama.

Ada batasan jumlah total file dalam satu direktori. Sepertinya saya ingat itu pasti berfungsi hingga 32000 file.

Ingatlah bahwa di Linux jika Anda memiliki direktori dengan terlalu banyak file, shell mungkin tidak dapat memperluas wildcard. Saya memiliki masalah ini dengan album foto yang dihosting di Linux. Ini menyimpan semua gambar yang diubah ukurannya dalam satu direktori. Sementara sistem file dapat menangani banyak file, shell tidak bisa. Contoh:

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

atau

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

Saya sedang mengerjakan masalah yang sama sekarang. Kami memiliki struktur direktori hierarki dan menggunakan id gambar sebagai nama file. Misalnya, gambar dengan id=1234567ditempatkan di

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

menggunakan 4 digit terakhir untuk menentukan ke mana file pergi.

Dengan beberapa ribu gambar, Anda dapat menggunakan hierarki satu tingkat. Sysadmin kami menyarankan tidak lebih dari beberapa ribu file dalam direktori tertentu (ext3) untuk efisiensi / cadangan / apa pun alasan lain yang ada dalam pikirannya.

Untuk apa nilainya, saya baru saja membuat direktori pada ext4sistem file dengan 1.000.000 file di dalamnya, kemudian secara acak mengakses file-file tersebut melalui server web. Saya tidak melihat adanya premium saat mengaksesnya (katakanlah) hanya memiliki 10 file di sana.

Ini sangat berbeda dari pengalaman saya melakukan ini pada ntfsbeberapa tahun yang lalu.

Masalah terbesar yang saya temui adalah pada sistem 32-bit. Setelah Anda melewati angka tertentu, alat seperti 'ls' berhenti bekerja.

Mencoba melakukan apa saja dengan direktori itu setelah Anda melewati penghalang itu menjadi masalah besar.

Saya pernah mengalami masalah yang sama. Mencoba menyimpan jutaan file di server Ubuntu di ext4. Berakhir menjalankan tolok ukur saya sendiri. Menemukan bahwa direktori datar berkinerja lebih baik sekaligus lebih mudah digunakan:

Menulis sebuah artikel .

Jika waktu yang diperlukan untuk mengimplementasikan skema partisi direktori minimal, saya mendukungnya. Pertama kali Anda harus men-debug masalah yang melibatkan memanipulasi direktori 10.000 file melalui konsol Anda akan mengerti.

Sebagai contoh, F-Spot menyimpan file foto sebagai YYYY \ MM \ DD \ filename.ext, yang berarti direktori terbesar yang harus saya tangani saat memanipulasi koleksi foto ~ 20000-foto saya secara manual adalah sekitar 800 file. Ini juga membuat file lebih mudah dijelajahi dari aplikasi pihak ketiga. Jangan pernah berasumsi bahwa perangkat lunak Anda adalah satu-satunya yang akan mengakses file perangkat lunak Anda.

Ini benar-benar tergantung pada sistem file. Banyak filesystem modern menggunakan struktur data yang layak untuk menyimpan isi direktori, tetapi filesystem lama sering hanya menambahkan entri ke daftar, jadi mengambil file adalah operasi O (n).

Sekalipun filesystem melakukannya dengan benar, masih sangat mungkin bagi program yang membuat daftar isi direktori kacau dan melakukan sortir O (n ^ 2), jadi untuk amannya, saya selalu membatasi jumlah file per direktori tidak lebih dari 500.

Itu sangat tergantung pada sistem file yang digunakan, dan juga beberapa flag.

Sebagai contoh, ext3 dapat memiliki ribuan file; tetapi setelah beberapa ribu, biasanya sangat lambat. Sebagian besar saat mendaftar direktori, tetapi juga ketika membuka satu file. Beberapa tahun yang lalu, ia memperoleh opsi 'htree', yang secara dramatis mempersingkat waktu yang diperlukan untuk mendapatkan inode yang diberi nama file.

Secara pribadi, saya menggunakan subdirektori untuk menjaga level paling bawah di bawah seribu atau lebih item. Dalam kasus Anda, saya akan membuat 256 direktori, dengan dua digit hex terakhir dari ID. Gunakan angka terakhir dan bukan angka pertama, sehingga Anda mendapatkan beban yang seimbang.

ext3 sebenarnya memiliki batas ukuran direktori, dan mereka bergantung pada ukuran blok sistem file. Tidak ada "jumlah maks" file per direktori, tetapi "jumlah blok maksimum per-direktori" yang digunakan untuk menyimpan entri file ". Secara khusus, ukuran direktori itu sendiri tidak dapat tumbuh melebihi b-tree dengan tinggi 3, dan fanout dari pohon tergantung pada ukuran blok. Lihat tautan ini untuk beberapa detail.

https://www.mail-archive.com/[email protected]/msg01944.html

Saya digigit oleh ini baru-baru ini pada sistem file yang diformat dengan blok 2K, yang entah bagaimana mendapatkan pesan kernel penuh direktori warning: ext3_dx_add_entry: Directory index full!ketika saya menyalin dari sistem file ext3 lain. Dalam kasus saya, direktori dengan hanya 480.000 file tidak dapat disalin ke tujuan.

Pertanyaannya adalah apa yang akan Anda lakukan dengan file tersebut.

Di bawah Windows, direktori apa pun dengan file lebih dari 2k cenderung terbuka lambat untuk saya di Explorer. Jika semuanya file gambar, lebih dari 1k cenderung terbuka sangat lambat dalam tampilan thumbnail.

Pada suatu waktu, batas yang diberlakukan sistem adalah 32.767. Ini lebih tinggi sekarang, tetapi bahkan itu terlalu banyak file untuk ditangani pada satu waktu di sebagian besar keadaan.

Yang gagal ditunjukkan oleh sebagian besar jawaban di atas adalah bahwa tidak ada jawaban "Satu Ukuran Sesuai Semua" untuk pertanyaan awal.

Dalam lingkungan saat ini kami memiliki banyak konglomerat perangkat keras dan perangkat lunak yang berbeda - ada yang 32 bit, ada 64 bit, ada yang mutakhir dan ada yang dicoba dan benar - dapat diandalkan dan tidak pernah berubah. Ditambah lagi dengan berbagai perangkat keras yang lebih baru dan lebih baru, OS yang lebih tua dan lebih baru, vendor yang berbeda (Windows, Unix, Apple, dll.) Dan berbagai utilitas dan server yang berjalan bersama. Seiring dengan peningkatan perangkat keras dan perangkat lunak yang dikonversi ke kompatibilitas 64 bit, tentu ada penundaan yang cukup besar dalam mendapatkan semua bagian dari dunia yang sangat besar dan kompleks ini untuk bermain dengan baik dengan laju perubahan yang cepat.

IMHO tidak ada satu cara untuk memperbaiki masalah. Solusinya adalah untuk meneliti kemungkinan dan kemudian dengan coba-coba menemukan yang terbaik untuk kebutuhan khusus Anda. Setiap pengguna harus menentukan apa yang berfungsi untuk sistem mereka daripada menggunakan pendekatan cookie cutter.

Saya misalnya memiliki server media dengan beberapa file yang sangat besar. Hasilnya hanya sekitar 400 file yang mengisi drive 3 TB. Hanya 1% dari inode yang digunakan tetapi 95% dari total ruang digunakan. Orang lain, dengan banyak file yang lebih kecil mungkin kehabisan inode sebelum mereka hampir memenuhi ruang. (Pada sistem file ext4 sebagai aturan praktis, 1 inode digunakan untuk setiap file / direktori.) Sementara secara teoritis jumlah total file yang mungkin terkandung dalam direktori hampir tak terbatas, kepraktisan menentukan bahwa penggunaan keseluruhan menentukan unit yang realistis, bukan hanya kemampuan filesystem.

Saya berharap bahwa semua jawaban yang berbeda di atas telah mempromosikan pemikiran dan pemecahan masalah daripada menghadirkan hambatan yang tidak dapat diatasi untuk maju.

Saya ingat menjalankan sebuah program yang menciptakan sejumlah besar file pada output. File-file itu diurutkan pada 30000 per direktori. Saya tidak ingat mengalami masalah membaca ketika saya harus menggunakan kembali output yang dihasilkan. Itu pada laptop Linux Ubuntu 32-bit, dan bahkan Nautilus menampilkan konten direktori, meskipun setelah beberapa detik.

ext3 filesystem: Kode serupa pada sistem 64-bit ditangani dengan baik dengan 64000 file per direktori.

"Tergantung pada sistem file"
Beberapa pengguna menyebutkan bahwa dampak kinerja tergantung pada sistem file yang digunakan. Tentu saja. Filesystem seperti EXT3 bisa sangat lambat. Tetapi bahkan jika Anda menggunakan EXT4 atau XFS Anda tidak dapat mencegah bahwa daftar folder melalui lsatau findatau melalui koneksi eksternal seperti FTP akan menjadi lebih lambat lebih lambat.

Solusi
Saya lebih suka cara yang sama dengan @armandino . Untuk itu saya menggunakan fungsi kecil ini di PHP untuk mengubah ID menjadi filepath yang menghasilkan 1000 file per direktori:

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

atau Anda bisa menggunakan versi kedua jika Anda ingin menggunakan karakter alfa-numerik:

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

hasil:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

Seperti yang Anda lihat untuk versi- $intsetiap folder berisi hingga 1000 file dan hingga 99 direktori yang berisi 1000 file dan 99 direktori ...

Tetapi jangan lupa bahwa banyak direktori menyebabkan masalah kinerja yang sama!

Akhirnya Anda harus memikirkan cara mengurangi jumlah file secara total. Bergantung pada target Anda, Anda dapat menggunakan sprite CSS untuk menggabungkan beberapa gambar kecil seperti avatar, ikon, smilies, dll. Atau jika Anda menggunakan banyak file kecil non-media pertimbangkan untuk menggabungkannya misalnya dalam format JSON. Dalam kasus saya, saya memiliki ribuan cache mini dan akhirnya saya memutuskan untuk menggabungkannya dalam paket 10.

Saya menghargai ini tidak sepenuhnya menjawab pertanyaan Anda tentang berapa banyak terlalu banyak, tetapi ide untuk memecahkan masalah jangka panjang adalah bahwa selain menyimpan metadata file asli, juga menyimpan folder pada disk yang disimpan dalam - normalisasi mengeluarkan sepotong metadata. Setelah folder tumbuh melampaui batas yang Anda rasa nyaman untuk kinerja, estetika atau alasan apa pun, Anda cukup membuat folder kedua dan mulai menjatuhkan file di sana ...

Saya mengalami masalah serupa. Saya mencoba mengakses direktori dengan lebih dari 10.000 file di dalamnya. Butuh waktu terlalu lama untuk membangun daftar file dan menjalankan semua jenis perintah pada salah satu file.

Saya memikirkan script php kecil untuk melakukan ini untuk diri saya sendiri dan mencoba mencari cara untuk mencegahnya dari waktu habis di browser.

Berikut ini adalah skrip php yang saya tulis untuk mengatasi masalah tersebut.

Mendaftarkan File di Direktori dengan terlalu banyak file untuk FTP

Bagaimana ini membantu seseorang

Bukan jawaban, tetapi hanya beberapa saran.

Pilih FS (sistem file) yang lebih cocok. Karena dari sudut pandang historis, semua masalah Anda cukup bijaksana, untuk menjadi pusat FS yang berkembang selama beberapa dekade. Maksud saya lebih modern FS lebih baik mendukung masalah Anda. Pertama-tama buat tabel keputusan perbandingan berdasarkan tujuan akhir Anda dari daftar FS .

Saya pikir sudah waktunya untuk mengubah paradigma Anda. Jadi saya pribadi menyarankan menggunakan sistem terdistribusi sadar FS , yang berarti tidak ada batasan sama sekali mengenai ukuran, jumlah file dan lain-lain. Jika tidak, Anda cepat atau lambat akan ditantang oleh masalah baru yang tidak terduga.

Saya tidak yakin untuk bekerja, tetapi jika Anda tidak menyebutkan beberapa eksperimen, cobalah AUFS dari sistem file Anda saat ini. Saya kira ia memiliki fasilitas untuk meniru beberapa folder sebagai folder virtual tunggal.

Untuk mengatasi batas perangkat keras Anda dapat menggunakan RAID-0.

Tidak ada angka tunggal yang "terlalu banyak", asalkan tidak melebihi batas OS. Namun, semakin banyak file dalam direktori, terlepas dari OS, semakin lama waktu yang dibutuhkan untuk mengakses file individual, dan pada kebanyakan OS, kinerjanya non-linear, sehingga untuk menemukan satu file dari 10.000 dibutuhkan lebih dari 10 kali lebih lama kemudian menemukan file dalam 1.000.

Masalah sekunder terkait dengan memiliki banyak file dalam direktori termasuk kegagalan ekspansi kartu liar. Untuk mengurangi risiko, Anda dapat mempertimbangkan memesan direktori berdasarkan tanggal pengunggahan, atau beberapa metadata lain yang bermanfaat.