Apakah sistem file ext3 / 4 mengakumulasi kesalahan secara alami (seperti yang dilaporkan oleh fsck)?

Saya menjalankan sejumlah server CentOS 6 64bit dengan sistem file ext3 / ext4. Sejauh yang saya tahu, tidak ada dari mereka yang dimatikan secara tidak benar, tetapi semuanya telah mengumpulkan beberapa kesalahan sistem file yang dilaporkan oleh fsck sekarang.

Sekarang, beberapa drive (bukan sistem file) memiliki kesalahan IO yang akan menyebabkan kegagalan hard drive (kita menjalankan raid1) jadi apakah itu mengarah ke kesalahan sistem file? Saya tidak berpikir kesalahan itu akan diizinkan untuk naik ke sistem file?

Setidaknya satu tidak menunjukkan tanda-tanda kegagalan hard drive tetapi memiliki kesalahan fsck.

Jadi, apakah sistem file ext3 / 4 menumpuk kesalahan secara alami dari waktu ke waktu atau ada sesuatu yang buruk terjadi?

— Shovas
sumber

Mengapa Anda berpikir kesalahan I / O tidak akan berinteraksi dengan kesalahan sistem file - jika kesalahan I / O membaca file, menurut Anda apa yang akan dilakukan sistem file? - Ini akan salah jika tidak dapat membaca file. Apa pun penyebabnya.

— djsmiley2k

Tanpa perincian lebih lanjut, sulit untuk mengatakan apa yang sebenarnya terjadi. ext3 cukup matang, saya belum melihat ada kesalahan akumulasi FS yang sebenarnya secara alami selama penggunaan selama bertahun-tahun. Kesalahan I / O yang tidak dapat dipulihkan (tidak mungkin untuk RAID 1) akan menyebabkan kesalahan FS jika terjadi di dalam struktur FS. Jika RAID 1 entah bagaimana mengacaukan pemulihan kesalahan (tidak memiliki pengalaman pribadi dengan itu), itu juga dapat menyebabkan kesalahan FS. Saya akan melihat dengan cermat di mana blok memiliki kesalahan, bagaimana raid berperilaku, dan blok mana yang menyebabkan kesalahan FS.

— dirkt

Terima kasih atas balasannya, @ djsmiley2k, @dirkt. Kesalahan IO yang dilaporkan oleh dmesgberada pada level perangkat, dan hanya pada satu perangkat, jadi saya pikir raid1 akan melakukan hal yang benar dari perangkat yang baik. Juga, setidaknya satu server tidak memiliki kesalahan drive tetapi memiliki kesalahan sistem file.

— Shovas

Jadi saya kira Anda menggunakan mdadm atau serangan perangkat lunak, bukan serangan perangkat keras?

— djsmiley2k

@ djsmiley2k Ya, perangkat lunak mdadm raid1 mirror.

— Shovas

Jawaban:

Kesalahan sistem file tidak menyebabkan kesalahan I / O yang tidak menyebabkan Kegagalan Hard Drive. Faktanya, kausalitas Anda sepenuhnya terbalik. Kegagalan Hard Drive menyebabkan kesalahan I / O, yang pada gilirannya menyebabkan kerusakan sistem file.

Kesalahan I / O akan dilaporkan sebagai kesalahan pada ruang pengguna. Dalam beberapa kasus ini dapat menyebabkan kerusakan sistem file (yang dapat diperbaiki oleh fsck), tetapi dalam beberapa kasus itu hanya dapat mengakibatkan korupsi blok data.

Jadi secara umum, itu tidak "normal" untuk korupsi sistem file untuk mengumpulkan dalam sistem file ext3 / ext4. Itu umumnya berarti Anda memiliki beberapa jenis masalah perangkat keras. Ini bisa jadi masalah memori; atau kegagalan hard drive; dll. Sebenarnya jika Anda melihat kesalahan I / O, Anda harus memperbaikinya terlebih dahulu. Bug perangkat lunak pada umumnya tidak menyebabkan kegagalan perangkat keras!

— Theodore Ts'o
sumber

Terima kasih telah merespons, @Theodore. Saya mengenali nama Anda dari membaca di sistem file :) Saya mengklarifikasi pertanyaan saya menjadi jelas saya tidak berpikir kesalahan FS menyebabkan kegagalan drive. Maksud saya, drive akan mengarah ke kesalahan FS di setup mdadm raid1 di mana satu drive bagus? Pasti perlu mengganti drive buruk itu tetapi di hosting dedicated server di dunia nyata (mis. 1and1.com) mereka sepertinya tidak ingin mengganti drive untuk mirror yang masih utuh: /.

— Shovas

Ditandai sebagai jawaban untuk mengonfirmasi bahwa kesalahan IO perangkat fisik dapat menyebabkan kesalahan FS: "Kesalahan I / O akan dilaporkan sebagai kesalahan pada ruang pengguna. Dalam beberapa kasus dapat menyebabkan kerusakan sistem file (yang dapat diperbaiki oleh fsck), tetapi dalam beberapa kasus itu hanya dapat mengakibatkan korupsi blok data. " Saya pasti berharap lebih dari satu jawaban pada waktu itu tetapi ini menjawab pertanyaan itu. Terima kasih

— Shovas

Ext3 adalah sistem file yang sepenuhnya andal, yang tidak berlaku untuk Ext4 (lebih tergantung pada Kernel)

Namun, beberapa kesalahan dapat dilakukan dari kabel / konektor data yang longgar, atau bahkan getaran / kejutan yang terjadi pada hard drive (mengenai casing PC dengan kaki Anda, memindahkan laptop Anda, dll.)

— X.LINK
sumber

Berapa banyak bug dalam basis kode sistem file tertentu akan tergantung pada versi kernel, tetapi secara umum ext4 sama andal, jika tidak lebih dapat diandalkan, daripada ext3. Faktanya ketika kita menggunakan ext4 untuk penggunaan produksi di Google, fakta bahwa ext4 berjalan pada banyak mesin, dan kita bisa mencari kegagalan yang berhubungan, berarti kita menemukan dan memperbaiki bug yang ada di ext3; tetapi sangat jarang bahwa itu bertahan beberapa proses pengujian sertifikasi Linux perusahaan. (Ini hampir pasti dipicu pada ext3, tapi itu mungkin dianggap sebagai kegagalan perangkat keras.)

— Theodore Ts'o

Nah, itu jawaban yang tidak terduga karena Anda adalah pengelola ext3 dan salah satu pembuat ext4 ... Di sisi lain, itu pasti akan sama untuk ext4, akan selalu ada bug yang bisa memakan waktu bertahun-tahun untuk dikenali sementara mereka tidak sekarang untuk perangkat lunak apa pun ... Tetapi meskipun saya telah memberi tahu diri saya sendiri banyak tentang dunia linux selama bertahun-tahun, bagaimana mungkin saya -dan juga banyak orang di internet- sadar tentang pemecahan masalah utama ext4 di 2.6? .30 kernel?!? Lagi pula, saya masih akan tetap menggunakan ext3 karena jatuh tempo dan mungkin akan beralih ke ext 4 ketika orang-orang akan melompat ke btrfs

— X.LINK