Berapa banyak file yang bisa saya masukkan ke dalam direktori?


561

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.

Jawaban:


736

FAT32 :

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

NTFS :

  • Jumlah file maksimum: 2 32  - 1 (4.294.967.295)
  • Ukuran file maksimum
    • Implementasi: 2 44  - 2 6 byte (16 TiB - 64 KiB)
    • Teoritis: 2 64  - 2 6 byte (16 EiB - 64 KiB)
  • Ukuran volume maksimum
    • Implementasi: 2 32  - 1 cluster (256 TiB - 64 KiB)
    • Teoritis: 2 64  - 1 cluster (1 YiB - 64 KiB)

ext2 :

  • Jumlah file maksimum: 10 18
  • Jumlah maksimum file per direktori: ~ 1,3 × 10 20 (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 13 , numberOfBlocks)
  • Ukuran file maksimum: sama dengan ext2
  • Ukuran volume maksimum: sama dengan ext2

ext4 :

  • Jumlah file maksimum: 2 32  - 1 (4.294.967.295)
  • Jumlah maksimum file per direktori: tidak terbatas
  • Ukuran file maksimum: 2 44  - 1 byte (16 TiB - 1)
  • Ukuran volume maksimum: 2 48  - 1 byte (256 TiB - 1)

24
Saya berasumsi ini adalah jumlah maksimum file untuk seluruh partisi, bukan direktori. Dengan demikian, informasi ini tidak terlalu berguna mengenai masalah tersebut, karena akan ada jumlah file yang sama terlepas dari metode (kecuali Anda menghitung direktori sebagai file).
strager

19
Karena kita berada di 2012 sekarang, saya pikir ini waktunya untuk menjelaskan bahwa ext4 tidak memiliki batasan mengenai jumlah subdirektori. Juga ukuran file maksimum bertambah menjadi 16 TB. Selanjutnya, ukuran keseluruhan sistem file mungkin hingga 1 EB = 1.048.576 TB.
devsnd

7
Rupanya, ext3 juga memiliki batas 60.000 file (atau direktori atau tautan) per direktori. Saya menemukan cara yang sulit tentang ini.
stackular

8
Jawaban lama, saya tahu ... tetapi ketika Anda menulis EXT4 - Jumlah maksimum file: 2³² - 1 (4.294.967.295) dan Jumlah maksimum file per direktori: tidak terbatas Anda benar-benar membingungkan saya karena 2³² - 1! = "Tidak terbatas". Kurasa aku butuh kopi sekarang. ;) Namun demikian +1
e-sushi

11
Batas filesystem keras tidak menjawab pertanyaan " Apakah penting berapa banyak file yang saya simpan dalam satu direktori? "
Etki

191

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.


6
Baca menarik! Bisakah saya bertanya dalam situasi apa Anda memiliki 8 juta file dalam satu direktori? haha
A

Saya memiliki hal yang sama. Saya telah memigrasikan kolom gumpalan sebuah tabel, setiap kolom gumpalan saya telah diekspor sebagai file. Sekitar 8 juta file :)
Spike

65

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 .


6
Ini adalah satu-satunya jawaban yang berguna. Kami telah membuat pengalaman serupa. Batas kami adalah 1.000 file untuk mengurangi masalah dengan cadangan (terlalu banyak direktori juga memperlambat).
mgutt

1
Dapat bermanfaat untuk memasang drive dengan noatime juga: howtoforge.com/... dan baca ini juga: serverfault.com/questions/354017/…
mgutt

2
Sistem file apa yang Anda gunakan di mana ia sangat melambat? XFS, misalnya, harus dapat dengan mudah menangani 100.000 file dalam direktori tanpa perlambatan nyata.
Ethan

1
Bertentangan dengan pendapat kebanyakan orang, saya ingin mengkonfirmasi jawaban ini. Kami memiliki ratusan ribu gambar di situs web jejaring sosial kami. Untuk meningkatkan kinerja kami terpaksa memiliki 100 (atau 1000 untuk beberapa file) sub direktori dan mendistribusikan file ke dalamnya (ext3 di linux + Apache untuk kami).
wmac

57

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.


4
Gnome dan KDE memuat direktori besar dengan kecepatan siput, windows akan men-cache direktori sehingga masuk akal. Saya suka Linux, tetapi kde dan gnome ditulis dengan buruk.
benteng

1
Dan ext4 tampaknya memiliki setara dengan dir_index aktif secara default.
Kontrak Prof. Falken dilanggar

22
Ada batas sekitar 32K subdirektori dalam satu direktori di ext3, tetapi OP berbicara tentang file gambar. Tidak ada batasan (praktis?) Pada file dalam sistem file ext3 dengan Indeks Dir diaktifkan.
Peter N Lewis

1
Jawaban ini sudah usang, saat ini standarnya adalah ext4 .
Boris

1
"Tidak ada batasan (praktis?) Pada file dalam sistem file ext3 dengan Dir Index diaktifkan" - Saya baru saja kehabisan ruang file dalam direktori pada sistem file ext4 4TB, dengan dir_indexdiaktifkan. Saya memiliki sekitar 17 juta file di direktori. Jawabannya adalah untuk menghidupkan large_dirdengan tune2fs.
lunixbochs

49

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

33
@Steve, gunakan find (1) dan / atau xargs (1) untuk kasus ini. Untuk alasan yang sama, sebaiknya gunakan alat seperti itu dalam skrip alih-alih ekspansi baris perintah.
Dave C

3
Ssveve apakah Anda melihat kinerja turun ketika jumlah file dalam folder meningkat? Atau tidak ada hubungannya?
Pacerier

6
Ini adalah poin yang bagus tetapi untuk mengalah, alasan yang diberikan salah. Daftar argumen terlalu panjang bukan merupakan batasan shell, tetapi execimplementasi sistem . Shell biasanya dapat memperluas wildcard dengan baik - itu panggilan execdengan banyak argumen yang mengembalikan kesalahan.
jw013

Saya memiliki kesalahan yang sama tadi malam (Fedora 15) dengan "rm" (somefiles *) dengan sekitar ~ 400.000 file dalam direktori. Saya dapat memangkas file yang lebih lama dengan "find" ke titik di mana saya bisa "rm" dengan wildcard.
PJ Brunet

10.000.000 file ke direktori di etx4 berfungsi dengan baik. Tidak banyak hit kinerja saat mengakses. Namun agak lambat dengan wildcard. Hati-hati saat menggunakan program shell yang suka mengurutkan nama file! :)
Simon Rigét

25

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.


1
Ini solusi yang cukup bagus. Setiap tingkat direktori Anda hingga ke file akan memiliki paling banyak 100 entri di dalamnya jika Anda tetap dengan rincian 2 digit, dan direktori terbawah paling hanya akan memiliki 1 file.
RobKohr


21

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.


jenis file apa? teks atau gambar? Saya menggunakan ext4 dan harus mengimpor 80000 gambar dalam satu direktori di bawah wordpress dan ingin tahu apakah itu akan baik
Yvon Huynh

1
@YvonHuynh: Jenis file sama sekali tidak relevan. Biaya overhead dalam direktori daftar / pelacakan file adalah sama, apa pun yang terjadi.
TJ Crowder

14

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.


9

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:

patokan

Menulis sebuah artikel .


Tautan ke suatu solusi disambut baik, tetapi harap pastikan jawaban Anda bermanfaat tanpanya: tambahkan konteks di sekitar tautan sehingga teman-teman Anda akan mengetahui apa itu dan mengapa ada, lalu kutip bagian yang paling relevan dari halaman yang Anda tuju. menghubungkan kembali jika seandainya halaman target tidak tersedia. Jawaban yang sedikit lebih dari sebuah tautan dapat dihapus.
Samuel Liew

1
Menarik. Kami menemukan bahwa setelah 10.000 file kinerja menurun dengan sangat cepat sampai tidak dapat digunakan lagi. Kami memutuskan untuk memecah file menjadi subdirektori sekitar 100 pada setiap level untuk mencapai kinerja optimal. Saya kira moral dari cerita ini adalah untuk selalu membandingkannya dengan diri Anda di sistem Anda sendiri dengan persyaratan Anda sendiri.
Joshua Pinter

7

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.


6
Saya beriklan menentang pemartisian berdasarkan tanggal karena impor massal mungkin mengelompokkan file pada tanggal tertentu.
Maks.

Poin yang bagus. Anda harus mempertimbangkan kasus penggunaan Anda sebelum memilih skema partisi. Saya kebetulan mengimpor foto selama berhari-hari dalam distribusi yang relatif luas, DAN ketika saya ingin memanipulasi foto di luar tanggal F-Spot adalah cara termudah untuk menemukannya, jadi ini merupakan kemenangan ganda bagi saya.
Sparr

7

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.


7

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.


6
Jika nama file benar-benar acak, tidak masalah digit mana yang digunakan.
strager

Memang, nama file ini dihasilkan secara acak.
Kip

2
Atau gunakan byte N pertama dari SHA-1 digest dari nama file.
gawi

6

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/cwelug@googlegroups.com/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.


5

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.


5

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.


4

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.


4

"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.


3

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 ...


3

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


1

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.


1

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.