ext3 fsck time versus ukuran partisi

9

Saya sedang melakukan setup untuk farm penyimpanan skala besar, dan untuk menghindari kebutuhan fsck selama sebulan, rencana saya adalah untuk membagi penyimpanan menjadi banyak filesystem yang lebih kecil (ini baik-baik saja, karena saya memiliki pohon file yang sangat bagus , jadi saya bisa dengan mudah memiliki filesystem terpisah terpasang pada 1/, 2/, 3/, 4/, dll).

Kesulitan saya adalah dalam menemukan enumerasi apa ukuran "wajar" untuk sistem file, untuk menjaga waktu fsck sama "masuk akal". Sementara saya sepenuhnya menyadari bahwa waktu absolut untuk ukuran tertentu akan sangat tergantung pada perangkat keras, saya sepertinya tidak dapat menemukan deskripsi bentuk kurva untuk kali fsck ext3 dengan berbagai ukuran sistem file, dan apa variabel lainnya ( apakah sistem file penuh dengan file dalam satu direktori membutuhkan waktu lebih lama dari satu dengan 10 file di masing-masing ribuan direktori di pohon; file besar vs file kecil; sistem file penuh vs filesystem kosong, dan sebagainya).

Apakah ada yang punya referensi ke nomor yang diteliti dengan baik tentang ini? Gagal bahwa, setiap anekdot tentang masalah ini setidaknya harus membantu memandu eksperimen saya sendiri, jika itu diperlukan.

EDIT : Untuk memperjelas: terlepas dari sistem file, jika ada yang salah dengan metadata, itu perlu diperiksa. Apakah re-fscks berbasis waktu atau mount diaktifkan atau diperlukan tidak dipermasalahkan, dan satu-satunya alasan saya meminta nomor khusus mengenai ext3 adalah karena itulah sistem file yang paling mungkin untuk dipilih. Jika Anda mengetahui sistem file yang memiliki proses fsck yang sangat cepat, saya terbuka untuk saran, tetapi itu perlu opsi yang kuat (klaim bahwa "sistem file X tidak perlu fscking!" Akan ditertawakan dan diejek panjang lebar) . Saya juga menyadari perlunya cadangan, dan keinginan untuk fsck bukan pengganti untuk cadangan, namun hanya membuang sistem file dan memulihkan dari cadangan ketika glitches, daripada fscking, sepertinya benar-benar,

womble
sumber

Jawaban:

6

Menurut sebuah makalah oleh Mathur et al. (hal. 29), waktu e2fsck tumbuh secara linier dengan jumlah inode pada sistem file setelah titik tertentu. Jika grafik dapat digunakan, Anda lebih efektif dengan sistem file hingga 10 juta inode.

Beralih ke ext4 akan membantu - dengan syarat sistem file Anda tidak dimuat hingga penuh, di mana keuntungan kinerja (karena tidak memeriksa inode yang ditandai tidak digunakan) tidak memiliki efek yang dapat dilihat.

towo
sumber
Terima kasih untuk referensi itu, membantu mengkonfirmasi beberapa hal untuk saya. Saya juga melakukan pembandingan sendiri, yang menghasilkan pertumbuhan linear yang ditunjukkan dalam makalah itu.
womble
2

Saya pikir Anda harus melakukan benchmarking sendiri. Pencarian cepat di Google tidak mengungkapkan apa pun, kecuali bahwa ext4 fscks jauh lebih cepat daripada ext3.

Jadi, buat beberapa partisi ext3, 100GB, 200GB, dll hingga ukuran disk yang akan Anda gunakan. Kemudian isi dengan data. Jika Anda dapat menggunakan data yang menyerupai data produksi Anda, (file per direktori, distribusi ukuran file, dll.) Maka itu yang terbaik. Perhatikan bahwa hanya menyalin file dari perangkat cadangan lain partisi akan menempatkannya pada disk yang ditata dan didefrag dengan sempurna sehingga pengujian Anda akan kekurangan banyak kepala disk mencari waktu yang akan datang dari banyak menulis / memodifikasi / menghapus.

Anda juga perlu memikirkan fscks paralel. Lihat beberapa bidang terakhir di / etc / fstab. Partisi pada disk fisik yang sama harus dilakukan secara berurutan; beberapa disk pada pengontrol yang sama dapat dilakukan secara paralel, tetapi berhati-hatilah untuk tidak membebani pengontrol dan memperlambatnya.

pgs
sumber
-1

apakah ada alasan mengapa Anda tidak dapat menggunakan sistem file yang tidak memaksa fscks berbasis waktu dan mount pada Anda ketika Anda reboot?

(fsck berbasis waktu benar-benar menggangguku - untuk server jangka panjang, cukup banyak jaminan bahwa Anda harus melakukan fsck penuh setiap kali Anda meningkatkan kernel).

Lagi pula, XFS adalah salah satu sistem file penjurnalan yang tidak memaksa fsck. layak untuk dilihat.

cas
sumber
pilihan lain adalah menggunakan Nexenta (opensolaris kernel, debian userland), yang akan memberi Anda ZFS. <a href=" nexenta.org/"> http://www.nexenta.org/</A >
cas
3
Ketika filesystem rusak, terlepas dari apa itu (extN, XFS, ZFS, apa pun), atau apakah Anda memiliki waktu / mount berdasarkan hitungan, itu membutuhkan fsck. Saya ingin memastikan bahwa satu filesystem yang rusak tidak membutuhkan waktu terlalu lama untuk fsck.
womble
1
ya, tentu saja fs perlu fsck jika sudah rusak. menggunakan fs seperti XFS tidak akan menghilangkannya, Anda juga tidak boleh mencoba atau bahkan ingin. Saya tidak mengatakan apa pun yang bisa diartikan sebaliknya. Maksud saya adalah bahwa memaksa fsck hanya karena sudah X banyak hari atau banyak gunung sejak fsck terakhir tidak perlu dan menjengkelkan dan bahkan mungkin "membatasi karir", terutama jika pengguna Anda atau perusahaan Anda sedang menunggu server datang kembali. Anda dapat menghilangkan fscks yang tidak perlu itu, dan melakukannya adalah Good Thing.
cas
Sebaik apapun (atau mungkin tidak), itu tidak menjawab pertanyaan yang diajukan.
womble