Sistem fail dibina di atas peranti storan. Terdapat pengawal RAID dan pengawal cakera yang masing-masing menjalankan sepotong firmware sendiri. Terdapat cache untuk meningkatkan persembahan. Terdapat cakera dengan ukuran sektor yang berbeza dan ada disk yang akan melaporkan ukuran sektor yang berbeza bergantung pada bagaimana anda mengajukan pertanyaan.

Dengan begitu banyak bahagian yang berbeza yang merupakan timbunan simpanan biasa, adalah keajaiban bahawa apa-apa berfungsi sama sekali. Walau bagaimanapun, banyak perkara berjalan lancar. Beberapa kali berlaku, kita memerlukan utiliti seperti xfs_repair untuk mengeluarkan kita dari kekacauan.

Masalah boleh menjadi salah semasa anda menulis fail dan kehabisan kuasa atau terdapat keran panik. Malah data yang tidak aktif di dalam cakera mungkin merosot dari masa ke masa kerana struktur fizikal elemen memori boleh berubah, ini dikenali sebagai bit reput. Dalam semua kes, kita memerlukan mekanisme untuk:

1. Memeriksa data yang dibaca adalah data yang sama dengan yang terakhir ditulis. Ini dilaksanakan dengan memiliki checksum untuk setiap blok data dan membandingkan checksum untuk blok tersebut ketika data sedang dibaca. Sekiranya checksum sepadan, data tidak dapat diubah
2. Kaedah untuk menyusun semula data yang rosak atau hilang, sama ada dari blok cermin atau dari blok pariti.

Persediaan kotak pasir

Mari sediakan testbench untuk menjalankan rutin pembaikan xfs dan bukannya menggunakan cakera sebenar dengan data berharga di atasnya. Sekiranya anda sudah mempunyai sistem fail yang rosak, anda boleh melangkau bahagian ini dan melompat ke kanan ke yang berikutnya. Testbench ini terdiri daripada Ubuntu VM yang disambungkan cakera maya yang menyediakan penyimpanan mentah. Anda boleh menggunakan VirtualBox untuk membuat VM dan kemudian membuat cakera tambahan untuk dilampirkan ke VM.

Pergi ke tetapan VM anda dan di bawahnya Tetapan → Storan bahagian anda boleh menambah cakera baru ke pengawal SATA anda boleh membuat cakera baru. Seperti yang ditunjukkan di bawah, tetapi pastikan VM anda dimatikan semasa anda melakukan ini.

Setelah cakera baru dibuat, hidupkan VM dan buka terminal. Arahan lsblk menyenaraikan semua peranti blok yang ada.

$ lsblk
sda 8: 0 0 60G 0 cakera
├─sda1 8: 1 0 1M 0 bahagian
Dasda2 8: 2 0 60G 0 bahagian /
sdb 8:16 0 100G 0 cakera
sr0 11: 0 1 1024M 0 rom

Selain dari peranti blok utama sda, di mana OS dipasang, kini terdapat peranti sdb baru. Mari kita buat partition dengan cepat dan format dengan sistem fail XFS.

Buka utiliti berpisah sebagai pengguna root:

$ berpisah -a optimum / dev / sdb

Mari buat jadual partisi terlebih dahulu menggunakan mklabel, ini diikuti dengan membuat partisi tunggal dari keseluruhan cakera (yang berukuran 107GB). Anda boleh mengesahkan bahawa partisi dibuat dengan menyenaraikannya menggunakan perintah cetak:

(berpisah) mklabel gpt
(berpisah) mkpart primer 0 107
(berpisah) cetakan
(berpisah) berhenti

Baiklah, sekarang kita dapat melihat menggunakan lsblk bahawa ada peranti blok baru di bawah peranti sdb, yang disebut sdb1.

Mari format storan ini sebagai xfs dan pasangkannya di direktori / mnt. Sekali lagi, lakukan tindakan berikut sebagai root:

$ mkfs.xfs / dev / sdb1
$ mount / dev / sdb1 / mnt
$ df -h

Perintah terakhir akan mencetak semua sistem fail yang dipasang dan anda boleh memastikan bahawa / dev / sdb1 dipasang di / mnt.

Seterusnya kami menulis sekumpulan fail sebagai data palsu untuk defragment di sini:

$ dd if = / dev / urandom of = / mnt / myfile.kiraan txt = 1024 bs = 1024

Perintah di atas akan menulis fail myfile.txt saiz 1MB. Sekiranya anda mahu, anda boleh menghasilkan lebih banyak fail seperti itu secara automatik, menyebarkannya ke pelbagai direktori di dalam sistem fail xfs (dipasang di / mnt) dan kemudian periksa pemecahan. Gunakan bash atau python atau bahasa skrip kegemaran anda untuk ini.

Kesalahan Pemeriksaan dan Pembaikan

Kerosakan data dapat masuk ke dalam cakera anda secara senyap tanpa pengetahuan anda. Sekiranya blok data tidak dibaca dan checksum tidak dibandingkan, ralat mungkin muncul pada masa yang salah. Semasa seseorang cuba mengakses data, dalam masa nyata. Sebaliknya, adalah idea yang baik untuk menjalankan imbasan menyeluruh semua blok data untuk memeriksa kerosakan bit atau kesalahan lain dengan kerap.

Utiliti xfs_scrub sepatutnya melakukan tugas ini untuk anda. Terinspirasi sebahagiannya oleh arahan scrub OpenZFS, ciri eksperimen ini hanya tersedia pada versi xfsprogs 4.15.1-1ubuntu1 yang bukan pelepasan stabil. Sekiranya salah mengesan kesalahan, ia mungkin menyesatkan anda sehingga menyebabkan kerosakan data dan bukannya memperbaikinya! Walau bagaimanapun, jika anda ingin bereksperimen dengannya, anda boleh menggunakannya pada sistem fail yang dipasang menggunakan perintah:

$ xfs_scrub / dev / sdb1

Sebelum mencuba memperbaiki sistem fail yang rosak, pertama sekali anda mesti melepaskannya. Ini untuk menghentikan aplikasi daripada menulis secara tidak sengaja ke sistem fail apabila ia sepatutnya dibiarkan begitu sahaja.

$ umount / dev / sdb1

Kesalahan pembaikan semudah berjalan:

$ xfs_repair / dev / sdb1

Metadata penting selalu disimpan sebagai beberapa salinan, walaupun anda tidak menggunakan RAID dan jika ada yang salah dengan superblok atau inod maka perintah ini dapat menyelesaikan masalah itu untuk anda kemungkinan besar.

Langkah seterusnya

Sekiranya anda sering melihat kerosakan data (atau bahkan sekali, jika anda menjalankan misi yang penting) pertimbangkan untuk mengganti cakera anda kerana ini mungkin merupakan petunjuk awal cakera yang akan hampir mati.

Sekiranya pengawal gagal, atau kad RAID telah berhenti hidup, maka tidak ada perisian di dunia yang dapat memperbaiki sistem fail untuk anda. Anda tidak mahukan bil pemulihan data yang mahal dan anda juga tidak mahu downtime yang panjang, jadi perhatikan SSD dan pinggan berputar tersebut!