Apa sistem file Linux berperforma paling tinggi untuk menyimpan banyak file kecil (HDD, bukan SSD)?

43

Saya memiliki pohon direktori yang berisi banyak file kecil, dan sejumlah kecil file yang lebih besar. Ukuran rata-rata file adalah sekitar 1 kilobyte. Ada 210158 file dan direktori di pohon (angka ini diperoleh dengan menjalankan find | wc -l).

Sebagian kecil file ditambahkan / dihapus / ditulis ulang beberapa kali per minggu. Ini berlaku untuk file kecil, serta ke (jumlah kecil) file yang lebih besar.

Filesystem yang saya coba (ext4, btrfs) memiliki beberapa masalah dengan posisi file pada disk. Dalam rentang waktu yang lebih lama, posisi fisik file pada disk (memutar media, bukan solid state disk) menjadi lebih terdistribusi secara acak. Konsekuensi negatif dari distribusi acak ini adalah bahwa sistem file semakin lambat (seperti: 4 kali lebih lambat dari sistem file baru).

Apakah ada sistem file Linux (atau metode pemeliharaan sistem file) yang tidak mengalami penurunan kinerja ini dan mampu mempertahankan profil kinerja yang stabil pada media yang berputar? Sistem file dapat berjalan pada Fuse, tetapi harus dapat diandalkan.

linux filesystems performance
sumber
Jika Anda tahu file mana yang besar / tidak berubah sangat sering, dan mana yang kecil / sering berubah, Anda mungkin ingin membuat dua sistem file dengan opsi berbeda pada mereka, lebih cocok untuk setiap skenario. Jika Anda ingin mereka dapat diakses karena mereka adalah bagian dari struktur yang sama, Anda dapat melakukan beberapa trik dengan mount, symlink.
Marcin
Saya cukup terkejut mengetahui bahwa btrfs (dengan fitur copy-on-write) telah lambat bagi Anda selama periode waktu tertentu. Saya ingin mengetahui hasil yang dibagikan dari Anda, mungkin membantu satu sama lain dalam arah baru penyesuaian kinerja dengannya.
Nikhil Mulley
ada zfs online hewan baru di Linux, tersedia dalam mode asli dan implementasi sekering, jika Anda ingin melihatnya.
Nikhil Mulley
Saya mencoba zfs di linux sekali, cukup tidak stabil. Berhasil sepenuhnya mengunci sistem file. Kotak akan berfungsi, tetapi akses ke FS akan hang.
Patrick
Postingan serupa serverfault.com/questions/6711/…
Nikhil Mulley

Jawaban:

47

Performa

Saya menulis Benchmark kecil ( sumber ), untuk mencari tahu, sistem file apa yang berkinerja terbaik dengan ratusan ribu file kecil:

  • buat 300000 file (512B hingga 1536B) dengan data dari / dev / urandom
  • tulis ulang 30000 file acak dan ubah ukurannya
  • membaca 30000 file berurutan
  • baca 30000 file acak

  • hapus semua file

  • sinkronkan dan lepas cache setelah setiap langkah

Hasil (waktu rata-rata dalam detik, lebih rendah = lebih baik):

Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s

Hasil:
Sementara Ext4 memiliki kinerja keseluruhan yang baik, ReiserFS sangat cepat dalam membaca file berurutan. Ternyata XFS lambat dengan banyak file kecil - Anda tidak boleh menggunakannya untuk kasus penggunaan ini.

Masalah fragmentasi

Satu-satunya cara untuk mencegah sistem file dari mendistribusikan file melalui drive, adalah untuk menjaga partisi hanya sebesar yang Anda benar-benar membutuhkannya, tetapi perhatikan untuk tidak membuat partisi terlalu kecil, untuk mencegah fragmentasi-intrafile. Menggunakan LVM bisa sangat membantu.

Bacaan lebih lanjut

Arch Wiki memiliki beberapa artikel hebat yang berhubungan dengan kinerja sistem file:

https://wiki.archlinux.org/index.php/Beginner%27s_Guide#Filesystem_types

https://wiki.archlinux.org/index.php/Maximizing_Performance#Storage_devices

taffer
sumber
4
Anda harus menentukan versi kernel apa yang mendasari perbandingan itu. XFS mendapat beberapa kecepatan impor yang sangat signifikan di salah satu kernel baru-baru ini (pikir itu 2.6.31, tapi jangan mengutip saya tentang itu).
Patrick
1
btrfs secara internal melakukan trik lvm Anda. Ini mengalokasikan potongan yang lebih kecil dari disk dan menempatkan file dalam potongan tersebut, kemudian hanya mengalokasikan potongan lain dari disk ketika potongan yang ada terisi.
psusi
1
Itu berlaku untuk semua sistem file. Itu sebabnya aplikasi menggunakan hal-hal seperti fsync ().
psusi
2
@taffer, itu. Transaksi memiliki efek yang sama seperti jurnal dalam sistem file lain: mereka melindungi metadata fs. Secara teori mereka dapat digunakan oleh aplikasi dengan cara yang Anda gambarkan, tetapi saat ini tidak ada api untuk memungkinkan aplikasi untuk membuka dan menutup transaksi.
psusi
1
@taffer "Patokan terbaru" Anda berasal dari April 2015, lebih dari tiga tahun dan menggunakan XFS dengan hanya opsi default. Ini pra-tanggal xfsprogs 3.2.3 yang menjadikan XFS v5 sebagai default dan semua manfaat yang dibawanya. Itu juga tidak diformat dengan -m finobt = 1 yang merupakan game-changer untuk kinerja XFS dengan file kecil dan pembaruan metadata yang berat. Tidak, tidak ada peluru perak, tetapi mendasarkan pendapat Anda pada tolok ukur lama dengan tidak bijaksana, terutama ketika fitur-fitur utama yang mengubah kinerja diabaikan, tidak tersedia, atau dinonaktifkan.
Jody Lee Bruchon
7

Saya menggunakan ReiserFS untuk tugas ini, terutama dibuat untuk menangani banyak file kecil. Ada teks yang mudah dibaca di funtoo wiki.

ReiserFS juga memiliki sejumlah fitur yang ditujukan khusus untuk meningkatkan kinerja file kecil. Tidak seperti ext2, ReiserFS tidak mengalokasikan ruang penyimpanan dalam satu k atau empat k blok tetap. Sebagai gantinya, ia dapat mengalokasikan ukuran persis yang dibutuhkannya.

Baarn
sumber
1
Ada masalah stabilitas juga dengan ReiserFS - jadi RH dan SuSE telah menjatuhkan FS itu. Dari prinsip (BTree-based-FS) BTRFS harus sebanding.
Nils
0

XFS terkenal memiliki kinerja yang sangat baik dalam situasi seperti ini. Ini adalah bagian dari mengapa kami menggunakannya di tempat kerja saya untuk toko surat kami (yang dapat berisi ratusan ribu file dalam 1 direktori). Ini memiliki toleransi kesalahan yang lebih baik daripada ReiserFS, digunakan lebih luas, dan umumnya merupakan sistem file yang sangat matang.

Selain itu, XFS mendukung defragmentasi online. Meskipun ia menggunakan teknik alokasi tertunda yang menghasilkan fragmentasi lebih sedikit (vs filesystem lain) untuk memulai.

Patrick
sumber
20
XFS terkenal karena berperforma sangat baik dalam situasi seperti ini. [rujukan?]
taffer
8
Ehm, xfs terutama dikenal untuk sebaliknya: bekerja sangat baik dengan file besar, tetapi tidak begitu baik pada file kecil! Lihatlah contoh lengkap ini (atau lompat langsung ke kesimpulan di halaman 10 ^^): ilsistemista.net/index.php/linux-a-unix/…
Levite
1
@Levit Saya pikir Anda salah membaca laporan itu. Laporan tersebut dengan sangat jelas menunjukkan bahwa XFS berkinerja sangat baik untuk IO acak. Tapi selain itu, laporan itu tidak membahas jenis skenario dalam pertanyaan ini, banyak file. IO acak adalah satu hal, sejumlah besar file adalah tempat ext * jatuh di wajahnya.
Patrick
2
Satu-satunya tempat XFS benar-benar lebih baik ada operasi baca / tulis acak (masih tampak aneh bahwa pola baca yang benar-benar acak pada disk mekanis bisa mendapatkan 10MB / s - bagi saya seperti beberapa optimasi yang tidak terbang di dunia nyata. (imho)), sedangkan pada halaman 7 itu menunjukkan apa yang saya katakan sebelumnya, XFS sangat bagus dalam menangani file besar! Lihat halaman 3 & 5, khususnya pada 3 Anda melihatnya menangani file kecil jelas tidak serta ext! Saya benar-benar tidak memiliki apa-apa terhadap XFS, tetapi dari apa yang Anda temukan di mana-mana, itu bukan optiom terbaik untuk banyak file kecil, itu saja yang saya katakan!
Levite
5
XFS juga bisa sangat lambat dalam hal file besar, jika file ini diperpanjang secara acak / lambat dengan potongan kecil dalam waktu yang lama. ( syslogdPola khas .) Misalnya di sisi saya dalam XFS lebih dari pengaturan MD saya baru saja mengamati, bahwa menghapus file 1,5 GB butuh 4,75 menit (!) Sementara drive disk dibatasi pada batas 100 transaksi / s pada tingkat penulisan lebih dari 2 MB / s. Ini juga berdampak pada kinerja operasi IO paralel lainnya pada drive yang sama dengan buruk, karena drive sudah dimaksimalkan. Tidak pernah melihat hal seperti itu di FS lain (atau sedang diuji dalam tolok ukur).
Tino