TL; Ringkasan DR : Terjemahkan nomor sektor md ke dalam offset di dalam /dev/mdXperangkat, dan bagaimana cara menyelidikinya xfs_db. Nomor sektor berasal dari sh->sectordalam linux/drivers/md/raid5.c:handle_parity_checks5().
Saya tidak tahu internal MD, jadi saya tidak tahu persis apa yang harus dilakukan dengan output dari printklogging yang saya tambahkan.
Offset ke perangkat komponen (untuk ddatau hex editor / viewer) juga akan menarik.
Saya kira saya harus menanyakan ini di milis Linux-raid. Apakah hanya pelanggan, atau bisakah saya memposting tanpa berlangganan?
Saya memiliki xfs langsung di atas MD RAID5 dari 4 disk di desktop saya (tidak ada LVM). Lulur baru-baru ini mendeteksi non-nol mismatch_cnt(8 pada kenyataannya, karena md beroperasi pada halaman 4kiB sekaligus).
Ini adalah RAID5, bukan RAID1 / RAID10 di mana mismatch_cnt! = 0 dapat terjadi selama operasi normal . (Tautan lain di bagian bawah halaman wiki ini mungkin berguna bagi sebagian orang.)
Saya hanya bisa membabi buta repair, tapi kemudian saya tidak tahu file mana untuk memeriksa kemungkinan korupsi, selain kehilangan kesempatan untuk memilih cara merekonstruksi mana. Jawaban Frostschutz pada pertanyaan serupa adalah satu-satunya saran yang saya temukan untuk melacak kembali perbedaan dalam sistem file. Ini rumit dan lambat, dan saya lebih suka menggunakan sesuatu yang lebih baik untuk mempersempitnya menjadi beberapa file terlebih dahulu.
Patch kernel untuk menambahkan logging
Anehnya, fitur cek md tidak melaporkan di mana kesalahan ditemukan . Saya menambahkan printkdi md / raid5.c untuk login sh->sectordi ifcabang yang bertahap mddev->resync_mismatchesdalamhandle_parity_checks5() (sepetak kecil yang diterbitkan pada github , awalnya didasarkan pada 4,5-RC4 dari kernel.org.) Untuk ini ok untuk penggunaan umum, mungkin akan perlu hindari membanjiri log dalam perbaikan dengan banyak ketidakcocokan (mungkin hanya login jika nilai baru resync_mismatches<1000?). Mungkin juga hanya masuk checkdan tidak repair.
Saya cukup yakin saya mencatat sesuatu yang bermanfaat (walaupun saya tidak tahu MD internal!), Karena fungsi yang sama mencetak nomor sektor dalam kasus penanganan kesalahan dariswitch .
Saya mengkompilasi kernel yang dimodifikasi dan mem-boot-nya, lalu menjalankan ulang pemeriksaan:
[ 399.957203] md: data-check of RAID array md125
...
[ 399.957215] md: using 128k window, over a total of 2441757696k.
...
[21369.258985] md/raid:md125: check found mismatch at sector 4294708224 <-- custom log message
[25667.351869] md: md125: data-check done.
Sekarang saya tidak tahu persis apa yang harus dilakukan dengan nomor sektor itu. Apakah sh->sector * 512alamat linear di dalam /dev/md/t-r5(alias /dev/md125)? Apakah ini nomor sektor dalam setiap perangkat komponen (jadi ini mengacu pada tiga data dan satu sektor paritas)? Saya menduga yang terakhir, karena paritas-ketidakcocokan dalam RAID5 berarti N-1 sektor perangkat md berada dalam bahaya, diimbangi satu sama lain oleh unit stripe. Apakah sektor 0 merupakan permulaan dari perangkat komponen, atau apakah itu sektor setelah superblok atau semacamnya? Apakah ada informasi lebih lanjut handle_parity_checks5()yang seharusnya saya hitung / login?
Jika saya hanya ingin mendapatkan blok yang tidak cocok, apakah ini benar?
dd if=/dev/sda6 of=mmblock.0 bs=512 count=8 skip=4294708224
dd if=/dev/sdb6 of=mmblock.1 bs=512 count=8 skip=4294708224
dd if=/dev/sda6 of=mmblock.2 bs=512 count=8 skip=4294708224
dd if=/dev/sdd of=mmblock.3 bs=512 count=8 skip=4294708224 ## not a typo: my 4th component is a smaller full-disk
# i.e.
sec_block() { for dev in {a,b,c}6 d; do dd if=/dev/sd"$dev" of="sec$1.$dev" skip="$1" bs=512 count=8;done; }; sec_block 123456
Saya kira tidak, karena saya mendapatkan 4k nol dari keempat komponen serangan, dan 0^0 == 0, sehingga harus menjadi paritas yang benar, bukan?
Satu tempat lain yang pernah saya lihat menyebutkan menggunakan alamat sektor dalam md adalah untuk sync_mindan sync_max(dalam sysfs). Neil Brown di daftar linux-raid , dalam menanggapi pertanyaan tentang drive yang gagal dengan nomor sektor dari hdrecover, di mana Neil menggunakan nomor sektor disk penuh sebagai nomor sektor MD. Itu tidak benar kan? Bukankah angka sektor md relatif terhadap perangkat komponen (partisi dalam kasus itu), bukan perangkat lengkap yang menjadi bagian dari partisi?
sektor linear ke nama file XFS:
Sebelum menyadari bahwa nomor sektor md mungkin untuk komponen, bukan perangkat RAID, saya mencoba menggunakannya dalam read-only xfs_db:
Saran yang sangat singkat dari Dave Chinner tentang bagaimana menemukan bagaimana XFS menggunakan blok yang diberikan tampaknya tidak bekerja sama sekali untuk saya. (Saya akan mengharapkan semacam hasil, untuk beberapa sektor, karena jumlahnya tidak boleh melebihi akhir perangkat bahkan jika itu bukan sektor yang tidak cocok)
# xfs_db -r /dev/md/t-r5
xfs_db> convert daddr 4294708224 fsblock
0x29ad5e00 (699227648)
xfs_db> blockget -nv -b 699227648
xfs_db> blockuse -n # with or without -c 8
must run blockget first
Hah? Apa yang saya lakukan salah di sini? Saya kira ini harus menjadi pertanyaan terpisah. Saya akan mengganti ini dengan tautan jika / ketika saya bertanya atau menemukan jawaban untuk bagian ini di tempat lain.
RAID5 saya pada dasarnya idle, tanpa aktivitas tulis dan minimal baca (dan noatime, jadi baca tidak menghasilkan penulisan).
Banyak hal tambahan tentang pengaturan saya, tidak ada yang penting di sini
Banyak file saya adalah video atau data terkompresi lainnya yang memberikan cara efektif untuk mengetahui apakah data itu benar atau tidak (baik checksum internal dalam format file, atau hanya apakah itu diterjemahkan tanpa kesalahan). Itu akan membuat metode loopback read-only ini layak, setelah saya tahu file mana yang harus diperiksa. Saya tidak ingin menjalankan diff 4-arah dari setiap file di sistem file untuk menemukan ketidakcocokan pertama, ketika kernel memiliki informasi yang diperlukan saat memeriksa, dan dapat dengan mudah mencatatnya.
my /proc/mdstatuntuk array data massal saya:
md125 : active raid5 sdd[3] sda6[0] sdb6[1] sdc6[4]
7325273088 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 0/19 pages [0KB], 65536KB chunk
Ada di partisi pada tiga drive Toshiba 3TB, dan drive hijau (lambat) WD25EZRS non-partisi yang saya ganti dengan Toshiba lain. (Menggunakan mdadm --replaceuntuk melakukannya secara online tanpa celah dalam redundansi. Saya menyadari setelah satu salinan bahwa saya harus memeriksa kesehatan RAID sebelum dan sesudahnya, untuk mendeteksi masalah. Saat itulah saya mendeteksi ketidakcocokan. Mungkin sudah ada sejak lama. , sejak saya mengalami crash hampir setahun yang lalu, tapi saya tidak punya log lama dan mdadm sepertinya tidak mengirim email tentang ini secara default (Ubuntu 15.10).
Filesystem saya yang lain menggunakan perangkat RAID10f2 yang dibuat dari partisi sebelumnya pada tiga HD yang lebih besar (dan RAID0 untuk / var / tmp). RAID5 hanya untuk penyimpanan massal, bukan /homeatau /.
Drive saya baik-baik saja: jumlah kesalahan SMART adalah 0 semua penghitung blok buruk pada semua drive, dan tes mandiri SMART pendek + panjang berlalu.
duplikat dekat dari pertanyaan ini yang tidak memiliki jawaban:
- Potongan apa yang tidak cocok dalam larik md Linux?
- http://www.spinics.net/lists/raid/msg49459.html
- MDADM mismatch_cnt> 0. Apakah ada cara untuk mengidentifikasi blok mana yang tidak setuju?
- Hal-hal lain sudah ditautkan secara inline, tetapi terutama ide loopback read-only frostschutz .
- menggosok pada halaman Arch wiki RAID
.damagedatau sesuatu, daripada hanya tahu mungkin ada file yang rusak di suatu tempat.
mdadm -E /dev/xxx.