Pertama bagaimana saya sampai dalam situasi ini:
Saya memiliki array RAID5 dengan disk masing-masing 2TB (disk USB eksternal), saya kemudian ingin membuat array terenkripsi yang lebih besar. Oleh karena itu saya mendapat 2 disk tambahan (masing-masing juga 2 TB) dan rencananya adalah menjalankan array asli dalam mode terdegradasi, mengatur array terenkripsi baru, menyalin sebagian data, setelah itu mengecilkan array asli ke mode 2 disk terdegradasi, perbesar yang baru, salin sisa data dan terakhir perbesar ke 7 disk RAID5 non-degradasi. Saya melakukan seluruh prosedur dengan /dev/loopX perangkat masing-masing 2 GB untuk menguji apakah paket saya memiliki peringatan.
Semuanya berjalan baik dengan array yang sebenarnya sampai ke titik di mana salah satu disk baru gagal. Ketika saya mengganti yang ini, urutan disk yang dikenali oleh kernel berubah setelah reboot berikutnya (/dev/sdb , /dev/sdc , … semua disk yang berbeda dari sebelumnya). Semuanya menjadi kacau dan saya tidak menyadarinya sampai salah satu disk disinkronkan kembali sebagai anggota array yang salah. Saya menyimpan detail cerita ini dan langsung ke intinya:
Saya sekarang memiliki satu larik terenkripsi, RAID5 3-disk, terdegradasi pada /dev/sdc1 dan /dev/sdd1 , berjalan dengan baik, semua data di sana dan sistem file yang sehat menurut fsck -f .
Sejauh ini bagus.
Seluruh masalah sekarang menjadi 3 disk – saya tidak dapat membuat array yang tidak terenkripsi ini berfungsi lagi. Saya cukup yakin datanya TELAH berada di sana di /dev/sdf1 , /dev/sdg1 , /dev/sdh1 , karena ini adalah larik yang berfungsi tepat sebelum SATU disk mungkin menjadi kacau (secara tidak sengaja disinkronkan ulang sebagai anggota larik terenkripsi lainnya, seperti yang dikatakan sebelumnya). Jadi, salah satu dari tiga disk ini mungkin memiliki data array yang salah, tetapi yang mana? Dan dua di antaranya harus bagus, tapi bagaimana cara mengetahuinya?
Saya mencoba setiap permutasi mdadm --create … dengan /dev/sdf1 , /dev/sdg1 , /dev/sdh1 dan "hilang" seperti:
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdf1 /dev/sdg1 missing
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdf1 missing /dev/sdg1
...dan tentu saja diperiksa setiap saat dengan
fsck /dev/md0
yang mengeluhkan superblok yang tidak valid.
Setiap kali mdadm membuat array, tetapi tidak ada sistem file yang dapat dibaca, hanya berisi sampah, tidak ada permutasi yang digunakan dengan mdadm yang akhirnya berhasil.
Jadi pertanyaan saya sekarang:Opsi apa yang tersisa? Selain kehilangan data saya dan membangun kembali array dari awal, tentu saja.
Berikut beberapa info tambahan (semua disk):
mdadm --examine /dev/sdb1
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : cfee26c0:414eee94:e470810c:17141589
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:38:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3906759680 (3725.78 GiB 4000.52 GB)
Used Dev Size : 3906759680 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : f4f0753e:56b8d6a5:84ec2ce8:dbc933f0
Update Time : Sun Oct 28 11:38:32 2012
Checksum : 60093b72 - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdc1
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 5cb45bae:7a4843ba:4ad7dbfb:5c129d2a
Name : merlin:1 (local to host merlin)
Creation Time : Wed Sep 26 07:32:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 9e2f9ae6:6c95d05e:8d83970b:f1308de0
Update Time : Fri Oct 26 03:26:37 2012
Checksum : 79d4964b - correct
Events : 220
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdd1
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 5cb45bae:7a4843ba:4ad7dbfb:5c129d2a
Name : merlin:1 (local to host merlin)
Creation Time : Wed Sep 26 07:32:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 98b07c41:ff4bea98:2a765a6b:63d820e0
Update Time : Fri Oct 26 03:26:37 2012
Checksum : 6e2767e8 - correct
Events : 220
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sde1
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 6db9959d:3cdd4bc3:32a241ad:a9f37a0c
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 12:12:59 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905299943 (1862.19 GiB 1999.51 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 677a4410:8931e239:2c789f83:e130e6f7
Update Time : Sun Oct 28 12:12:59 2012
Checksum : 98cb1950 - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : A.A ('A' == active, '.' == missing)
mdadm --examine /dev/sdf1
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3700a0a6:3fadfd73:bc74b618:a5526767
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:28:30 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905392640 (1862.24 GiB 1999.56 GB)
Array Size : 3905391616 (3724.47 GiB 3999.12 GB)
Used Dev Size : 3905391616 (1862.24 GiB 1999.56 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 5a8a5423:10b7a542:26b5e2b3:f0887121
Update Time : Sun Oct 28 11:28:30 2012
Checksum : 8e90495f - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdg1
/dev/sdg1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 202255c9:786f474d:ba928527:68425dd6
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:24:36 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905299943 (1862.19 GiB 1999.51 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 4605c729:c290febb:92901971:9a3ed814
Update Time : Sun Oct 28 11:24:36 2012
Checksum : 38ba4d0a - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdh1
/dev/sdh1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 682356f5:da2c442e:7bfc85f7:53aa9ea7
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 12:13:44 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906761858 (1862.89 GiB 2000.26 GB)
Array Size : 3906760704 (3725.78 GiB 4000.52 GB)
Used Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 489943b3:d5e35022:f52c917a:9ca6ff2a
Update Time : Sun Oct 28 12:13:44 2012
Checksum : f6947a7d - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdc1[0] sdd1[1]
3905299456 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
unused devices: <none>
Bantuan apa pun akan sangat dihargai!
Terkait:Mengapa rsync tidak mengizinkan ukuran blok> 128K?Jawaban yang Diterima:
Jika Anda baru saja kehilangan satu disk, Anda harus telah dapat memulihkannya dengan menggunakan --assemble . yang jauh lebih aman .
Anda telah menjalankan create sekarang begitu banyak sehingga semua UUID berbeda. sdc1 dan sdd1 bagikan UUID (diharapkan, karena itu adalah larik kerja Anda)… disk lainnya memiliki nama yang sama, tetapi semuanya memiliki UUID yang berbeda. Jadi saya rasa tidak satu pun dari itu adalah superblok asli. Sayang sekali…
Bagaimanapun, saya kira Anda mencoba menggunakan disk yang salah, atau Anda mencoba menggunakan ukuran potongan yang salah (defaultnya telah berubah seiring waktu, saya percaya). Array lama Anda mungkin juga menggunakan versi superblok yang berbeda—defaultnya pasti telah berubah—yang dapat mengimbangi semua sektor (dan juga menghancurkan beberapa data). Terakhir, kemungkinan Anda menggunakan tata letak yang salah, meskipun kemungkinannya kecil.
Mungkin juga, larik pengujian Anda adalah baca-tulis (dari sudut pandang md) yang mencoba menggunakan ext3 benar-benar melakukan beberapa penulisan. Misalnya, pemutaran ulang jurnal. Tapi itu hanya jika menemukan superblok di beberapa titik, saya pikir.
BTW:Saya pikir Anda benar-benar harus menggunakan --assume-clean , meskipun tentu saja array yang terdegradasi tidak akan mencoba untuk mulai membangun kembali. Maka Anda mungkin ingin segera menyetel hanya-baca.