Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive
 

WD Red EFAX 2TBWD Red EFAX 2TB - WD Red EFAX 2TB
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.

Komentuoti


Apsaugos kodas
Atnaujinti