Kapan fsck berbahaya?

37

Baru-baru ini saya telah melihat sistem file root dari sebuah mesin di pusat data jarak jauh mendapatkan remount read-only, sebagai akibat dari masalah konsistensi.

Saat reboot, kesalahan ini ditunjukkan:

UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)

Setelah menjalankan fsck seperti yang disarankan, dan menerima koreksi secara manual dengan Y, kesalahan diperbaiki dan sistem sekarang baik-baik saja.

Sekarang, saya pikir itu akan menarik jika fsck dikonfigurasi untuk menjalankan dan memperbaiki semuanya secara otomatis, karena satu-satunya alternatif dalam beberapa kasus (seperti ini) adalah pergi sendiri ke pusat data jarak jauh dan memasang konsol ke mesin yang terpengaruh.

Pertanyaan saya adalah: mengapa fsck secara default meminta intervensi manual? Bagaimana dan kapan koreksi yang dilakukan oleh program semacam itu tidak aman? Kasus-kasus mana sysadmin mungkin ingin meninggalkan koreksi yang disarankan untuk beberapa waktu (untuk melakukan beberapa operasi lain) atau membatalkannya sama sekali?

— scristalli
sumber

15

Jika pengembang yakin 100% kesalahan bisa diperbaiki secara otomatis, maka itu bukan kesalahan.

— user253751

42

fsckpasti menyebabkan lebih banyak kerusakan daripada kebaikan jika perangkat keras yang mendasarinya rusak; CPU buruk, RAM buruk, hard drive sekarat, disk controller rusak ... dalam kasus-kasus lebih banyak korupsi tidak bisa dihindari.

Jika ragu, sebaiknya ambil gambar disk yang rusak dengan dd_rescueatau alat lain, lalu lihat apakah Anda berhasil memperbaiki gambar itu. Dengan begitu Anda masih memiliki pengaturan asli yang tersedia.

— Janne Pikkarainen
sumber

4

Saya sudah banyak bekerja dengan perangkat keras yang gagal dan saya setuju dengan ini. Hal terakhir yang ingin saya lakukan adalah fsck jika ada perangkat keras yang dicurigai buruk. Saya juga melihat kejadian daya rendah dan pemulihan selanjutnya yang sangat tertunda oleh fsck otomatis.

— jorfus

Untuk memberikan contoh konkret: Saya telah bekerja pada mesin dengan pengontrol disk yang "acak" (sekitar 1 kali dalam 10 ^ 5) akan mengubah pembacaan atau penulisan untuk memblokir XXXXXXYY pada perangkat apa pun menjadi penulisan untuk memblokir 000000YY pada perangkat pertama. Yaitu, ia sering mengecam data terstruktur yang salah dan tidak terstruktur ke sektor boot dan berbagai struktur sistem file penting dari disk boot. Menjalankan fsck dalam situasi seperti itu (jutaan bacaan) dapat menghilangkan peluang yang tersisa untuk memulihkan data.

— Eric Towers

2

1 dalam 10 ^ 5 banyak ... itu 10 byte, Mb.

— Nelson

1

@Nelson: Ini semacam ... Unit ada "transfer blok tunggal", bukan "byte". Jadi sepuluh blok buruk menulis per juta blok (dan blok secara signifikan lebih besar dari byte).

— Eric Towers

21

Anda telah melihat satu contoh di mana fsckberhasil, tetapi saya telah melihat lebih dari cukup sistem file yang rusak di mana itu tidak berhasil sama sekali. Jika itu akan bekerja sepenuhnya otomatis, Anda mungkin tidak memiliki kesempatan untuk melakukan hal-hal seperti dddump disk atau sesuatu seperti itu yang dalam banyak kasus akan menjadi ide bagus untuk dilakukan sebelum mencoba perbaikan.

Sama sekali tidak pernah merupakan ide bagus untuk mencoba hal seperti itu secara otomatis.

Oh, dan server modern harus memiliki konsol jarak jauh atau setidaknya, sistem penyelamatan independen untuk pulih dari sesuatu seperti itu tanpa menyeret rak KVM ke server.

— Sven
sumber

7

Sebenarnya, yang bukan ide yang baik adalah mengatakan " tidak pernah, pernah " seperti itu, ketika itu tidak benar. Kasus penggunaan di mana itu adalah ide yang baik: Partisi utama server dapat dibuat kembali dari awal dengan cepat, jika ada masalah. Sebenarnya data penting diakses melalui sistem file jarak jauh, dengan redundansi yang sesuai untuk data tersebut. Saya lebih suka mengambil kesempatan fsck -p /dan fsck -p /var, dll., Bekerja dengan baik, dan mendapatkan server tanpa intervensi manual, dan mengambil risiko kecil, peluang nol% dari malapetaka besar untuk partisi-partisi yang hanya bisa saya buat ulang jika diperlukan .

— TOOGAM

1

Jika sistem dapat dengan mudah diinstal ulang, saya hanya melakukan itu ...

— Sven

1

Itu akan memakan waktu lebih lama. Opsinya adalah: A) Risiko melakukannya secara otomatis. B) Minta seseorang fsckuntuk bersolek, dan kemudian semuanya bekerja dengan baik. Membutuhkan waktu sekitar 2 menit, jika itu. Downtime sampai ini terjadi. C) Suruh seseorang menginstal ulang sistem operasi. Membutuhkan waktu 30+ menit. Anda memilih opsi C? Mungkin perbedaan utama yang kami miliki adalah bahwa saya telah fsckmengerjakan persentase waktu yang lebih besar daripada apa yang Anda kutip dalam jawaban Anda. Poin utama saya bukanlah desain sistem (sistem murah ini tidak menggunakan konsol jarak jauh), tetapi hanya mengatakan " tidak pernah, " terlalu kuat frasa untuk menjadi akurat

— TOOGAM

Mari kita setuju untuk tidak setuju.

— Sven

0

Pertama-tama, Anda perlu memahami bahwa dengan sistem file modern (dijurnal), kerusakan sistem tidak akan merusak sistem file dan tidak diperlukan fsck saat boot.

Ext3, Ext4, ZFS, btrfs, xfs, dan semua FS modern 100% konsisten setelah crash atau reset sistem.

FS yang tidak dijurnal seperti ext2 atau vfat adalah NOGO besar untuk rootfs sistem.

Sekarang, jika sistem Anda memerlukan fsck pada saat boot, Anda harus bertanya pada diri sendiri: apa alasan untuk ini?

Anda harus memeriksa log kernel setelahnya untuk mencari tahu, kapan dan apa yang terjadi. Anda juga harus kembali ke masa dalam log untuk menemukan sejak kapan kesalahan itu mulai. Anda harus memeriksa disk Anda dengan smartctl. Dll ... Jika Anda memerlukan fsck pada fs journalized, hampir pasti perangkat keras Anda gagal, dengan anggapan fs tidak rusak oleh admin (dengan alat level blok seperti dd) atau oleh bug.

Jadi konyol menggunakan fsck untuk "memperbaiki" masalah tanpa menyelidiki dan memperbaiki akar permasalahan (dengan mengganti / memutakhirkan perangkat keras / firmware / perangkat lunak yang rusak).

Melakukan fsck, menyelesaikan boot dan menjadi bahagia adalah naif untuk sedikitnya. Menyatakan "Saya memiliki pekerjaan fsck dalam persentase yang lebih besar daripada apa yang Anda kutip" membuat saya bertanya-tanya apa yang Anda maksud dengan "pekerjaan fsck". fsck mungkin telah mengembalikan fs Anda ke keadaan yang konsisten dengan kehilangan beberapa file dan data dalam proses ... Apakah Anda membandingkan dengan cadangan? Banyak orang kehilangan file atau mengalami kerusakan data file tanpa memperhatikan ...

— Francois Scheurer
sumber