Mengapa Anda tidak bisa fsck partisi yang dipasang?


43

Sudah diketahui umum bahwa Anda tidak boleh fsck partisi yang dipasang. Saya dapat memahami bagaimana ini dapat dengan mudah menyebabkan korupsi jika filesystem ditulis oleh fsck (misalnya, opsi -a digunakan), tetapi mengapa pemeriksaan read-only tidak dapat dijalankan pada disk yang terpasang?

Jawaban:


28

Dari:

http://linux.die.net/man/8/fsck.ext3

"Perhatikan bahwa secara umum tidak aman untuk dijalankan e2fsckpada filesystem mount. Satu-satunya pengecualian adalah jika -npilihan ditentukan, dan -c, -latau -Lpilihan yang tidak ditentukan. Namun, bahkan jika aman untuk melakukannya, hasilnya dicetak oleh e2fsckyang tidak valid jika filesystem sudah di-mount. Jika e2fsckditanya apakah Anda harus memeriksa atau tidak pada sistem file yang di-mount, satu-satunya jawaban yang benar adalah '' tidak ''. Hanya para ahli yang benar-benar tahu apa yang mereka lakukan harus mempertimbangkan untuk menjawab pertanyaan ini di yang lain cara. "


3
Satu pengecualian: jika filesystem di-mount read-only, dan fsck juga dalam mode read-only, maka semuanya OK
Demi

31

Masalah mendasarnya adalah bahwa pemeriksa sistem file (biasanya) bukan bagian dari sistem file. Sebaliknya itu adalah program terpisah yang membaca dan menulis ke disk yang sama dengan kode sistem file di kernel. Akibatnya, jika Anda menjalankan fsck pada sistem file yang aktif, Anda memiliki dua entitas berbeda yang membaca (dan berpotensi memodifikasi) data yang sama (disk), tetapi mereka tidak saling berkoordinasi dengan cara apa pun. Hasilnya, seperti yang telah ditunjukkan oleh orang lain, adalah bahwa sebagian besar checker berharap bahwa tidak ada orang lain yang mengubah metadata sistem file saat mereka berjalan. Mereka akan bingung dan / atau melaporkan kesalahan palsu jika sistem file kernel mengubah sesuatu yang tidak diharapkan oleh pemeriksa.

Ada beberapa sistem file dengan checker yang secara eksplisit dirancang untuk dijalankan "on-line" (yaitu, ketika sistem file aktif). Versi FFS / UFS yang lebih baru melakukan ini dengan menjalankan fsck terhadap snapshot sistem file terkini (replika read-only, point-in-time, copy-on-write). Jika menemukan masalah, seperti inkonsistensi dalam alokasi bit-peta, itu mengoreksi mereka melalui system call, bukan dengan menulis ke disk mentah. Ini memungkinkannya berkoordinasi dengan sistem file yang aktif.

WAFL NetApp juga memiliki alat pengecekan online. Mungkin ada yang lain.


11

Menjalankan fsck pada partisi yang dipasang baca-tulis akan konyol, bahkan dengan fsck dalam mode read-only. Filesystem akan berubah di bawah fsck, dan data dalam memori yang cache fsck dari filesystem akan menjadi tidak valid (dan dengan demikian fsck akan melihat inkonsistensi). Anda dapat menjalankan fsck pada sistem file yang dipasang hanya baca dalam mode baca-saja dan mendapatkan hasil yang valid. Menjalankan fsck dalam mode baca / tulis pada sistem file yang dipasang hanya baca, jika fsck membuat perubahan pada sistem file selama menjalankannya, akan menyebabkan kernel melihat struktur sistem file berubah secara tak terduga di bawahnya. Itu juga akan buruk.


Anda menulis "Menjalankan fsck dalam mode baca / tulis pada filsystem yang hanya dapat dibaca akan menyebabkan kernel melihat struktur sistem berkas berubah secara tak terduga di bawahnya". Mengapa struktur filesystem berubah pada read-only mount filsystem?
guettli

Menurut jawaban ini, fsck pada partisi read-only adalah ok, jika Anda reboot setelah bangsal: serverfault.com/a/405252/90324
guettli

@guettli - Jawaban yang Anda tautkan mengatakan hal yang sama seperti saya. (Saya memperbaiki kesalahan pengejaan saya, BTW. Terima kasih!) Jika fsck membuat perubahan sementara kernel memiliki mount file read-only cache data di dalam kernel mungkin menjadi tidak valid mengingat perubahan yang dilakukan oleh fsck. Tentu, Anda dapat mem-boot ulang sesudahnya. Anda mungkin juga menemukan bug kernel yang menarik dan panik kernel Anda sebelum Anda mendapatkan kesempatan untuk reboot juga.
Evan Anderson

9

Terlepas dari kenyataan bahwa itu mungkin akan membunuh throughput I / O Anda, jika filesystem sedang dimodifikasi saat sedang fsck maka tidak ada cara fsck bisa melacak perubahan dan melaporkan ketidaknyamanan.

Beberapa sistem file seperti XFS memungkinkan Anda melakukan pemeriksaan untuk konsistensi sementara sistem file di-mount baca-tulis, dengan peringatan bahwa kesalahan palsu kemungkinan akan dilaporkan. xfs_checkmerekomendasikan sistem file dilepas atau dipasang hanya-baca sebelum melakukan pemeriksaan.


6

Yah, maksud dari fsck adalah untuk melaporkan inkonsistensi sistem file, yang dilanggar oleh invarian.

Namun banyak dari pemeriksaan ini melibatkan lebih dari satu struktur FS. Jika seseorang memodifikasi FS (menulis data), struktur ini mungkin sementara tidak sinkron. fsck akan melihat ini sebagai inkonsistensi, meskipun sebenarnya tidak masalah. fsck tidak memiliki cara untuk mengetahui apakah inkonsistensi hanya bersifat sementara, atau masalah permanen yang perlu diperbaiki. Jadi ini tidak mungkin bekerja (Kecuali jika FS dirancang khusus untuk memungkinkan pengecekan online. Beberapa memang ada, tetapi ext3 tidak).


3

Anda bisa. fsck -n / dev / sda1 akan melakukan hal itu, setidaknya pada ext3. Saya baru saja mengujinya :)


-4

Anda dapat, sama seperti Anda dapat memasukkan tangan Anda ke dalam blender yang bergerak dan mungkin tidak melukai diri Anda sendiri, atau sama seperti Anda dapat melompat dari gedung tinggi sambil membidik tumpukan bantal yang Anda letakkan di trotoar di bawah ini.

Tetapi mengapa Anda, selain untuk menguji kematian Anda sendiri? Karena bos Anda pasti akan mengujinya lagi ketika dia tahu MENGAPA server email tidak akan mengenali drive root sekarang.


Sebenarnya, saya pikir analogi yang lebih baik adalah dengan melihat blender yang bergerak, atau melirik tepi gedung tinggi. Hanya baca.
Mike
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.