Filesystem sejumlah besar file dalam satu direktori

29

OK, tidak begitu besar tapi saya perlu menggunakan sesuatu di mana sekitar 60.000 file dengan ukuran rata-rata 30kb disimpan dalam satu direktori (ini adalah persyaratan sehingga tidak bisa begitu saja membobol sub-direktori dengan jumlah file yang lebih sedikit).

File-file akan diakses secara acak, tetapi sekali dibuat tidak akan ada menulis ke sistem file yang sama. Saya saat ini menggunakan Ext3 tetapi merasa sangat lambat. Ada saran?

bugmenot77
sumber
3
Mengapa mereka harus berada dalam satu direktori?
Kyle Brandt
1
Saya juga tertarik dengan jawaban terbaru untuk pertanyaan awal, cukup memberikan peningkatan pada xfs dan ext4.

Jawaban:

15

Anda harus mempertimbangkan XFS. Ini mendukung sejumlah besar file di sistem file dan di tingkat direktori, dan kinerjanya relatif konsisten bahkan dengan sejumlah besar entri karena struktur data pohon B +.

Ada halaman di wiki mereka untuk sejumlah besar makalah dan publikasi yang merinci desainnya. Saya sarankan Anda mencobanya dan membandingkannya dengan solusi Anda saat ini.

Kamil Kisiel
sumber
menurut slide dalam jawaban @ nelaar, ext4 akan lebih unggul daripada xfs untuk tugas ini.
mulllhausen
13

Satu miliar file di Linux

Penulis artikel ini menggali beberapa masalah kinerja pada sistem file dengan jumlah file besar dan melakukan beberapa perbandingan bagus kinerja berbagai sistem file ext3, ext4 dan XFS. Ini tersedia sebagai tampilan slide. http://events.linuxfoundation.org/slides/2010/linuxcon2010_wheeler.pdf

waktu untuk menjalankan mkfs waktu untuk membuat file 1M 50kb Waktu perbaikan sistem file menghapus file 1m

nelaaro
sumber
2
Kami benar-benar lebih suka jawaban berisi konten bukan petunjuk ke konten. Sementara ini secara teoritis dapat menjawab pertanyaan, akan lebih baik untuk memasukkan bagian-bagian penting dari jawaban di sini, dan menyediakan tautan untuk referensi.
user9517 mendukung GoFundMonica
@ Saya harap itu lebih baik, hanya dengan mengunduh PDF, akan memberikan Anda info yang sama.
nelaaro
19
wow ini adalah beberapa grafik yang sangat sulit dibaca. ~
ThorSummoner
8

Banyak file dalam direktori pada ext3 telah dibahas panjang lebar di situs saudara stackoverflow.com

Menurut pendapat saya 60 000 file dalam satu direktori pada ext3 jauh dari ideal tetapi tergantung pada kebutuhan Anda yang lain mungkin cukup bagus.

Ludwig Weinzierl
sumber
5

BAIK. Saya melakukan beberapa pengujian pendahuluan dengan menggunakan ReiserFS, XFS, JFS, Ext3 (dir_hash diaktifkan) dan Ext4dev (2.6.26 kernel). Kesan pertama saya adalah bahwa semuanya cukup cepat (pada workstation saya yang gemuk) - ternyata mesin produksi jarak jauh memiliki prosesor yang cukup lambat.

Saya mengalami beberapa keanehan dengan ReiserFS bahkan pada pengujian awal sehingga mengesampingkan itu. Tampaknya JFS memiliki persyaratan CPU 33% lebih sedikit daripada yang lain dan karenanya akan mengujinya di server jauh. Jika kinerjanya cukup baik, saya akan menggunakannya.

bugmenot77
sumber
5

Saya menulis sebuah aplikasi yang juga menyimpan banyak dan banyak file walaupun milik saya lebih besar dan saya punya 10 juta di antaranya yang akan saya bagi di beberapa direktori.

ext3 lambat terutama karena implementasi default "linked list". Jadi, jika Anda memiliki banyak file di satu direktori, itu berarti membuka atau membuat yang lain akan semakin lambat. Ada sesuatu yang disebut indeks htree yang tersedia untuk ext3 yang kabarnya meningkatkan banyak hal. Tapi, itu hanya tersedia pada pembuatan sistem file. Lihat di sini: http://lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/

Karena Anda harus membangun kembali sistem file dan karena keterbatasan ext3, rekomendasi saya adalah Anda ingin menggunakan ext4 (atau XFS). Saya pikir ext4 sedikit lebih cepat dengan file yang lebih kecil dan memiliki pembangunan kembali yang lebih cepat. Indeks Htree adalah default pada ext4 sejauh yang saya ketahui. Saya tidak benar-benar memiliki pengalaman dengan JFS atau Reiser tetapi saya telah mendengar orang merekomendasikan itu sebelumnya.

Pada kenyataannya, saya mungkin akan menguji beberapa filesystem. Mengapa tidak mencoba ext4, xfs & jfs dan lihat mana yang memberikan kinerja terbaik secara keseluruhan?

Sesuatu yang dikatakan oleh seorang pengembang kepada saya yang dapat mempercepat dalam kode aplikasi bukan untuk melakukan panggilan "stat + open" melainkan "open + fstat". Yang pertama secara signifikan lebih lambat dari yang kedua. Tidak yakin apakah Anda memiliki kendali atau pengaruh apa pun atas hal itu.

Lihat posting saya di sini di stackoverflow. Menyimpan & mengakses hingga 10 juta file di Linux ada beberapa jawaban dan tautan yang sangat berguna di sana.

Mat
sumber
3

Menggunakan tune2fs untuk mengaktifkan dir_index mungkin bisa membantu. Untuk melihat apakah itu diaktifkan:

sudo tune2fs -l /dev/sda1 | grep dir_index

Jika tidak diaktifkan:

sudo umount /dev/sda1   
sudo tune2fs -O dir_index /dev/sad1
sudo e2fsck -D /dev/sda1
sudo mount /dev/sda1

Tapi saya merasa Anda mungkin salah jalan ... mengapa tidak menghasilkan indeks datar dan menggunakan beberapa kode untuk memilih secara acak berdasarkan itu. Anda kemudian dapat menggunakan sub direktori untuk struktur pohon yang lebih optimal.

Kyle Brandt
sumber
1
adalah /dev/sad1disengaja untuk mencegah copy / pasta error?
Anwar
2

ext3 dan di bawah ini mendukung hingga 32768 file per direktori. ext4 mendukung hingga 65536 dalam jumlah sebenarnya file, tetapi akan memungkinkan Anda untuk memiliki lebih banyak (itu tidak akan menyimpannya di direktori, yang tidak masalah untuk sebagian besar keperluan pengguna).

Juga, cara direktori disimpan pada sistem file ext * pada dasarnya adalah sebagai satu daftar besar. Pada sistem file yang lebih modern (Reiser, XFS, JFS) mereka disimpan sebagai B-tree, yang jauh lebih efisien untuk set besar.

koenigdmj
sumber
2
mendukung jumlah file dalam direktori tidak sama dengan melakukannya dengan kecepatan yang wajar. saya belum tahu apakah ext4 lebih baik, tetapi ext3 sangat melambat ketika memiliki lebih dari beberapa ribu file dalam direktori, bahkan dengan dir_index dihidupkan (itu membantu, tetapi tidak menghilangkan masalah sama sekali).
cas
1

Anda dapat menyimpan inode file alih-alih nama file: mengakses nomor inode harus lebih cepat daripada menyelesaikan nama file

kolypto
sumber
Sekarang beritahu saya. Bagaimana Anda membuka file dengan nomor inode?
Matt
1
@ Mat, Sepertinya pertanyaan telah berubah setelah saya menjawab. Atau saya jauh lebih bodoh 1,5 tahun yang lalu :)))
kolypto
0

Anda tidak ingin menjejalkan banyak file dalam satu direktori, Anda ingin semacam struktur. Bahkan jika itu sesuatu yang sederhana seperti memiliki subdirektori yang dimulai dengan karakter pertama file dapat meningkatkan waktu akses Anda. Trik konyol lain yang saya suka gunakan, adalah memaksa sistem untuk memperbarui cache dengan metainformation adalah untuk menjalankan updatedb secara teratur. Di satu jendela jalankan slabtop, dan di jendela lain jalankan updateb dan Anda akan melihat banyak memori akan dialokasikan untuk caching. Jauh lebih cepat dengan cara ini.

Marcin
sumber
-1

Anda tidak menentukan jenis data dalam file ini. Tetapi dari bunyi-bunyinya, Anda harus menggunakan semacam database dengan pengindeksan untuk pencarian cepat.

xeon
sumber
-1

Filesystem mungkin bukan penyimpanan yang ideal untuk persyaratan seperti itu. Beberapa jenis penyimpanan basis data lebih baik. Namun jika Anda tidak dapat menahannya, maka coba pisahkan file dalam beberapa direktori dan gunakan unionfs untuk memasang (mengikat) direktori tersebut pada direktori tunggal di mana Anda ingin semua file muncul. Saya belum pernah menggunakan teknik ini untuk mempercepat sama sekali, tetapi patut dicoba.

Saurabh Barjatiya
sumber