Namų serveris pergyveno jau kelis atnaujinimus. Pernai seni WD Green diskai buvo pakeisti didesniais, o dar vėliau jie paraudonavo, keičiant 1.5 TB į 2 TB WD Red, kurie turėtų būti labiau pritaikyti NAS reikmėms. Tačiau migravimo į 2 TB diskus ilgam neužteko ir serveryje ėmė baigtis vieta - vien rezervinės kopijos užima per 800GB. Taigi vėl ėmiau sukti galvą, kur gauti daugiau vietos.

Paprasčiausias būdas - pirkti dar didesnius diskus. Bet tai brangu ir RAID1 nėra labai efektyvus disko erdvės panaudojimas. Taigi nusprendžiau RAID1 veidrodį pakeisti į RAID5 masyvą, kuriame duomenų saugumas remiasi kontrolinių sumų skaičiavimu. Naudojant Linux MD diskų masyvus, tai padaryti teoriškai yra labai paprasta. Tiesiog reikia "užauginti" RAID1 į "sugriuvusį" RAID5 ir paskui pridėti trūkstamą RAID5 diską. Ir taip nupirkus vieną papildomą diską, 2 TB veidrodis turėtų tapti 4 GB talpos RAID5 masyvu.

Ką gi, diskas buvo užsakytas prieš savaitę. Šiandien išjungiau serverį, įdėjau ir prijungiau diską ir įjungus kompiuterį niekas nesudegė. Pradžia nebloga. Tiesa, diena prieš tai visus svarbius duomenis iš serverio persikopijavau į 2 atskirus išorinius diskus. Taip dėl visa ko. :) Linux RAID dokumentacijoje masyvo migracija aprašyta labai glaustai:

mdadm --grow /dev/md/mirror --level=5
mdadm --grow /dev/md/mirror --add /dev/sdc1 --raid-devices=3

Kadangi serveryje yra 3 RAID1 masyvai, tai nusprendžiau pradėti nuo pačio mažiausio, skirto /boot skirsniui. 200MB masyvas buvo papildytas /dev/sdc1 įrenginiu per keletą sekundžių.

vm-serv:~# mdadm --detail /dev/md4
/dev/md4:
Version : 1.2
Creation Time : Sun Nov 20 17:38:04 2016
Raid Level : raid5
Array Size : 409216 (399.63 MiB 419.04 MB)
Used Dev Size : 204608 (199.81 MiB 209.52 MB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Tue Mar 3 20:10:07 2020
State : clean
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 64K

Consistency Policy : resync

Name : vm-serv:4 (local to host vm-serv)
UUID : 6327e994:0173727f:11c97dac:54b416b2
Events : 371

Number Major Minor RaidDevice State
2 8 17 0 active sync /dev/sdb1
3 8 1 1 active sync /dev/sda1
4 8 33 2 active sync /dev/sdc1

Kitas eilėje buvo /dev/md5 masyvas, kuriame yra serverio sistema. Šio masyvo pakeitimui reikėjo apie 40 min.

vm-serv:~# cat /proc/mdstat 
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md5 : active raid5 sdc2[4] sdb2[2] sda2[3]
104792064 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
[=======>.............] reshape = 38.9% (40797676/104792064) finish=23.6min speed=45023K/sec

md6 : active raid1 sdb3[0] sda3[1]
1848320064 blocks super 1.2 [2/2] [UU]
bitmap: 0/14 pages [0KB], 65536KB chunk

md4 : active raid5 sdc1[4] sdb1[2] sda1[3]
409216 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]

Na ir galiausiai eilė atėjo didžiausiam masyvui /dev/md6, kuris užima 1.72TB

vm-serv:~# pvs
PV VG Fmt Attr PSize PFree
/dev/md5 rootvg lvm2 a-- <99.91g 20.62g
/dev/md6 datavg lvm2 a-- 1.72t 62.06g

Paleidus migraciją, sistema nurodė, kad disko struktūros pakeitimui prireiks daugiau, nei 800 min.

vm-serv:~# cat /proc/mdstat 
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md5 : active raid5 sdc2[4] sdb2[2] sda2[3]
209584128 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md6 : active raid5 sdc3[2] sdb3[0] sda3[1]
1848320064 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
[>....................] reshape = 0.0% (497728/1848320064) finish=866.2min speed=35552K/sec
bitmap: 0/14 pages [0KB], 65536KB chunk

md4 : active raid5 sdc1[4] sdb1[2] sda1[3]
409216 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Viskas ėjosi, kaip iš pypkės, kol eidamas link katilinės nedirstelėjau serverio pusėn - pamirštame išjungti monitoriaus ekrane švietė gausybė eilučių. Atidarius serverinė spintos duris, ekrane mane pasitiko ponia Karma, atsukusi subinę...

Mar  3 20:06:14 vm-serv kernel: [ 3270.713074] ata5.00: failed command: READ FPDMA QUEUED
Mar 3 20:06:14 vm-serv kernel: [ 3270.704943] ata5.00: exception Emask 0x0 SAct 0x7fffffff SErr 0x0 action 0x0
Mar 3 20:06:14 vm-serv kernel: [ 3270.709055] ata5.00: irq_stat 0x40000008
Mar 3 20:06:14 vm-serv kernel: [ 3270.713074] ata5.00: failed command: READ FPDMA QUEUED
Mar 3 20:06:14 vm-serv kernel: [ 3270.717054] ata5.00: cmd 60/08:68:70:4c:f2/00:00:0d:00:00/40 tag 13 ncq dma 4096 in
Mar 3 20:06:14 vm-serv kernel: [ 3270.717054] res 41/40:00:70:4c:f2/00:00:0d:00:00/40 Emask 0x409 (media error) <F>
Mar 3 20:06:14 vm-serv kernel: [ 3270.725077] ata5.00: status: { DRDY ERR }
Mar 3 20:06:14 vm-serv kernel: [ 3270.717054] ata5.00: cmd 60/08:68:70:4c:f2/00:00:0d:00:00/40 tag 13 ncq dma 4096 in
Mar 3 20:06:14 vm-serv kernel: [ 3270.717054] res 41/40:00:70:4c:f2/00:00:0d:00:00/40 Emask 0x409 (media error) <F>
Mar 3 20:06:14 vm-serv kernel: [ 3270.725077] ata5.00: status: { DRDY ERR }
Mar 3 20:06:14 vm-serv kernel: [ 3270.729110] ata5.00: error: { UNC }
Mar 3 20:06:14 vm-serv kernel: [ 3270.729110] ata5.00: error: { UNC }
Mar 3 20:06:14 vm-ser v kernel: [ 3270.734416] ata5.00: configured for UDMA/133
Mar 3 20:06:14 vm-serv kernel: [ 3270.734478] sd 4:0:0:0: [sdb] tag#13 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Mar 3 20:06:14 vm-serv kernel: [ 3270.734481] sd 4:0:0:0: [sdb] tag#13 Sense Key : Medium Error [current]
Mar 3 20:06:14 vm-serv kernel: [ 3270.734484] sd 4:0:0:0: [sdb] tag#13 Add. Sense: Unrecovered read error - auto reallocate failed
Mar 3 20:06:14 vm-serv kernel: [ 3270.734487] sd 4:0:0:0: [sdb] tag#13 CDB: Read(10) 28 00 0d f2 4c 70 00 00 08 00
Mar 3 20:06:14 vm-serv kernel: [ 3270.734489] print_req_error: I/O error, dev sdb, sector 233983088
Mar 3 20:06:14 vm-serv kernel: [ 3270.736410] ata5: EH complete

#$#$@ !!! %$#$@@$ !!! Laimingiems, nemačiusiems tokių pranešimų - iššifruoju: serveryje buvęs /dev/sdb diskas dar veikia, bet ketina greit džiauti autus. Ir tai būtent pradėjus RAID1 migraciją į RAID5, kurią nutraukus visiems duomenims greičiausiai bus Kaput! Basta! Chajuk!

Atidžiau panagrinėjus ataskaitą, klaidos įvyko keičiant sisteminį masyvą ir /dev/md5 vertimas lyg ir pavyko. Kol kas pagrindinis duomenų masyvas keičiamas sėkmingai - daugiau klaidų ataskaitoje nesimato, nors pirmosios klaidos matytos dar Kovo 1 d. Taigi NAS įrenginiams skirti WD Red išgyveno ne ką ilgiau, nei mažų energijos sąnaudų WD Green. Kaip ten besibaigų masyvo keitimas - naują WD Red diską jau užsisakiau.

O istorijos moralas būtų toks: darykitės rezervines kopijas į kitus diskus, nei pagrindinė saugykla ir susitvarkite monitorinimą, kad tokios klaidos sugeneruotų perspėjimus, nes kasdien logų neskaitysite.