Nauji metai, nauji grėbliai. Skamba keistai, tačiau taip yra - dalis „WD Red“ diskų, kuriuos „Western Digital“ reklamuoja, kaip skirtus namų tinklo duomenų saugykloms (NAS) yra tam VISIŠKAI NETINKAMI. Jie yra iš principo nesuderinami su kai kuriomis failinėmis sistemomis ir/arba RAID masyvais. Diskai veiks, tačiau darbo sparta bus apgailėtina, kartais dešimtis kartų lėtesnė, nei kitų, atrodytų prastesnių charakteristikų diskų.
Jei trumpai, tai EFAX modelio 2-6 TB talpos „WD Red“ diskuose naudojama SMR (Shingled Magnetic Recording) technologija yra iš principo nesuderinama su dideliu skaičiumi atsitiktinių rašymo operacijų, kurios turi papildyti takelį. O kaip tik taip ir nutinka RAID masyvuose ar kai kuriose failinėse sistemose, dažnai naudojamose NAS įrenginiuose. Taip yra todėl, kad SMR technologijoje duomenų takelis turi būti perrašomas visas, jei greta jo esantis takelis turi duomenų. Taip yra todėl, kad disko magnetiniai duomenų takeliai yra surašomi labai tankiai ir beveik persidengia. Pagal duomenų rašymo algoritmą šie diskai primena elekroninius „Flash“ diskus, kur taip pat rašoma į laisvas atmintinės ląsteles, o išnaudojus laisvus blokus, imama trinti seniau „ištrinta“ informacija ir formuojami naujos laisvos atminties ląstelės. Kodėl „Western Digial“ nusprendė naudoti potencialiai lėtesnę technologiją? Atsakymas paprastas: į diską galima surašyti daugiau informacijos ir diskinį kaupiklį pagaminti pigiau.
Tai nėra didelė problema asmeniniame nešiojamajame diske ar vieno disko saugykloje (nebent naudojama BTRFS ar panaši failų sistema). Nuosekliai rašant duomenis į tokį diska, rašymo sparta irgi labai nekris, kol nesibaigs "laisvos" zonos. Bėda ta, kad „Western Digital“ nieko neperspėjusi SMR technologiją pradėjo naudoti raudonoji diskų serijoje, pakeisdama senuosus EFRX serijos PMR - Perpendicular Magnetic Recording( dar vadinamus CMR - Classic Magnetic Recording) diskus į EFAX seriją, naudojančius SMR technologiją. Ir toliau reklamavo „WD Red“, kaip tinkamus NAS. Dėl šios priežasties kompanija netgi buvo paduota į teismą, reikalaujant viešai pripažinti klaidą ir nustoti reklamuoti SMR Red diskus, kaip tinkamus NAS sistemoms.
Iki šiol kažkaip neatkreipiau į tai dėmesio, kol neprireikė į serverį įrašyti daugiau nei 300 GB failų. Sukopijavus pirmus 50-80GB, RAID disko skirsnyje baigės „laisvos“ zonos ir prasidėjo takelių perrašinėjimai. Rašymo greitis krito nuo 40MB/s iki 3-5 MB/s, o serverio apkrovos rodiklis (load) šoktelėjo iki 100, kai 4 branduolių sistemoje turėtų būti ne daugiau 4. Prireikė keleto valandų, kol žingsnis po žingsnio atsekiau, kad "blogai" veikia vienas kaupiklis. Būtent kabutėse, nes šiaip kaupiklis veikia taip, kaip numatė gamintojas, nors pirma mintis buvo, kad vėl pabiro RAID, nes diskui amba chajuk...
Paleidus top niekaip nepavyko suprasnti, kodėl pradėjus kopijuoti daug duomenų, serverio procesorius didžiąją laiko dalį praleidžia laukimo būsenoje („wa“ time parametras svyravo 60-90 proc. ribose). Buvo akivaizdu tik, kad kažkas negerai su diskine posisteme.
ATOP - vm-serv 2022/01/04 19:25:46 -------------- 10s elapsed
PRC | sys 2.28s | user 5.48s | #proc 323 | #zombie 0 | #exit 8 |
CPU | sys 19% | user 52% | irq 3% | idle 323% | wait 4% |
CPL | avg1 1.10 | avg5 1.08 | avg15 1.01 | csw 99426 | intr 76651 |
MEM | tot 15.6G | free 167.6M | cache 10.2G | buff 1.9G | slab 1.3G |
SWP | tot 28.0G | free 28.0G | | vmcom 12.4G | vmlim 35.8G |
LVM | datavg-media | busy 4% | read 26 | write 0 | avio 14.9 ms |
LVM | tavg-freenet | busy 4% | read 5 | write 4 | avio 41.3 ms |
LVM | rootvg-root | busy 1% | read 0 | write 180 | avio 0.78 ms |
MDD | md127 | busy 0% | read 0 | write 225 | avio 0.00 ms |
MDD | md6 | busy 0% | read 39 | write 4 | avio 0.00 ms |
DSK | sde | busy 14% | read 9 | write 8 | avio 75.8 ms |
DSK | sdd | busy 4% | read 14 | write 8 | avio 15.6 ms |
DSK | sdc | busy 3% | read 18 | write 6 | avio 13.2 ms |
NET | transport | tcpi 3274 | tcpo 4057 | udpi 143 | udpo 316 |
NET | network | ipi 4259 | ipo 5198 | ipfrw 826 | deliv 3433 |
NET | enp8s0 0% | pcki 1581 | pcko 2615 | si 246 Kbps | so 898 Kbps |
NET | lxc62ca 0% | pcki 462 | pcko 365 | si 256 Kbps | so 172 Kbps |
PID CID SYSCPU USRCPU VGROW RGROW RDDSK WRDSK S CPUNR CPU CMD 1/3
3270 host-------- 0.37s 2.26s 0K 90800K 0K 0K S 0 28% kube-apiserver
1781 host-------- 0.31s 0.79s 0K 0K 0K 0K S 2 12% kubelet
20678 host-------- 0.20s 0.67s 0K 0K 116K 0K S 3 9% java
2048 host-------- 0.07s 0.64s 0K 0K 0K 8K S 0 7% dockerd
3353 host-------- 0.27s 0.24s 0K 0K 0K 320K S 3 5% etcd
3379 host-------- 0.27s 0.17s 0K 0K 0K 0K S 1 5% kube-controlle
5332 host-------- 0.10s 0.16s 0K 0K 0K 0K R 3 3% atop
6322 host-------- 0.09s 0.09s 0K 0K 0K 0K S 2 2% cilium-agent
2217 host-------- 0.07s 0.03s 0K 0K 0K 0K S 1 1% sshd
3269 host-------- 0.04s 0.05s 0K 0K 0K 0K S 3 1% kube-scheduler
5454 host-------- 0.06s 0.03s 156K 100K 492K 0K S 2 1% transmission-d
7507 host-------- 0.00s 0.07s 0K 0K 0K 0K S 1 1% coredns
7032 ? 0.01s 0.05s 0K 0K - - E - 1% <cilium-cni>
7015 ? 0.01s 0.04s 0K 0K - - E - 1% <cilium-cni>
Beieškant būdų, kaip išaiškinti problemos šaltinį, internete pavyko rasti kitą sistemos stebėjimo priemonę: atop. Ją pasileidus - tapo akivaizdu, kad problema yra vienas konkretus kaupiklis. Kai kitų diskų apkrova nesiekė nė 10 proc., sde įrenginys buvo užimamas iki 100 proc. Net ir „nieko neveikiant“ disko apkrovimas siekia 15-20 proc. Akivaizdus buvo ir disko skaitymo/rašymo operacijų ilgis. Kai kitų diskų avio parametras svyravo 0-10 ms ribose, probleminio kaupiklio diskinės operacijos laikas buvo pasiekęs 900ms! Tai lėčiau, nei senas 4x CD-ROM kaupiklis (jei, kas dar tokius pamena)!
Taigi pradėjau knaisiotis, kokie diskai yra mano masyve ir aptikau, kad sdc ir sdd yra „WDC WD20EFRX“, tuo tarpu sde yra „WDC WD20EFAX“. Na, o tolimesni knaisiojimaisi po „DuckDuckGo“, naudojant įvairius raktažodžių derinius, atvedė prie šio Reddit puslapio, kur buvo nagrinėjama problema ir jame buvusios „Youtube“ nuorodos.
Visa tai reziumuojant, jei perkate diskinį kaupiklį, kurį ketinate naudoti NAS įrenginyje ar asmeniniame serveryje ir sujungti diskus į RAID masyvą, tai geriau venkite SMR technologiją naudojančių diskų. Kaip taisyklė tai yra pigesni tos pačios talpos ir tokiu pat greičiu besisukantys diskai. „Linux“ sistemoje tokius diskus galima išaiškinti šia komanda:
hdparm -I /dev/sde | grep -i trim
* Data Set Management TRIM supported (limit 10 blocks)
Diskiniai kaupikliai su magnetiniais besisukančiais diskais nėra suderinami su TRIM komandomis, kurios skirtos elektroninių kaupiklių atmintinės duomenų optimizavimui. Todėl kaupikliams su besisukančiais diskais ši komanda neturi gražinti jokios informacijos.
Kalbant apie „Western Digital“, tai „Red“ EFAX diskų serija yra SMR diskai, taip pat „Blue“ EZAZ, SPZX ir „Black“ SPSX kaupiklių serijos. „Red pro“ ir auksinės diskų serijos yra skirta našesniems NAS įrenginiams ir ten SMR technologija nėra naudojama. Gan išsamų kaupiklių modelių sąrašą rasite čia.