Az új WD RED-ek jók még raid-hez ?

Fórumok

Van itt egy cikk a HUP-on (2020 április 15-i lent balra )a WD red-ekről.  Idáig azt sem tudtam hogy létezik ilyen, hogy SMR hdd.

Ha igaz amit írnak, akkor az új WD RED (WDx0EFAX sorozat)  nem jó RAID-be, pedig idáig kifejezetten ajánlott volt. 

Többen is arről számolnak be, hogy raid újraépítés közben kidobja a lemezeket, annyira lelassúl. Ha jól értem ezekben a lemezekben 

van hagyományos és SMR-es terület, pihenő időben átpakol a hagyományosról az SMR -területre. Terhelésnél erre nincs ideje, nagyon  belassul, 

rebuild megszakad. 

Van erről valami tapasztalat ? 

Hozzászólások

Ennél jobb tapasztalatot nem találsz szerintem:

https://www.backblaze.com/b2/hard-drive-test-data.html

A WD RED-ről meg, nekem annyi van, hogy tavaly három Synology-t raktam összesen 14 db WD RED lemezzel, eddig egy romlott el, azt cseréltem ugyan olyanra. Rossz tapasztalatom nem volt. 

Egy, Egyből Kettő, Kettő meg Egy. Ez minden mérték alapja, minden élet csirája, számok, nevek építőköve.

Sajnos nem arról van szó, hogy elromlanak, hanem hogy random i/o terheléshez nem jók  ami pl. fellép egy resilvernél.

De ez csak az ősztől megjelent  WDx0EFAX -ra vonatkozik  ezek a régebbi  WDx0EFRX-sorozatot  váltották  le, és megváltozott a rögzítési technológia:

„Jelenleg a Western Digital WD Red 2TB-6TB meghajtói eszközvezérelt SMR (DMSMR). A WD Red 8TB-14TB meghajtók CMR-alapúak. 

Ezt az adatlapra nem irták ki, a régi  EFRX-ek CMR-esk voltak.

"a WD Red HDD dokumentációjában nem határozunk meg rögzítési technológiát. 

Egy tipikus kisvállalati / otthoni NAS-környezetben a munkaterhelések általában szétszóródnak a természetben,
elegendő időt hagyva a hulladékgyűjtéshez és más karbantartási műveletekhez.

A WD Red meghajtók tesztelésénél az SMR technológia miatt nem találtunk RAID-újjáépítési problémákat."

Több fórumon pedig találtak problémákat és újjáépítési gondokról írnak.

A Red Pro, illetve Ironwolf Pro ezt megoldhatja. Mi a legutóbbi NAS projekthez, ami még folyamatban van, mert a járványhelyzetben nem ez volt a legfontosabb, Seagate Ironwolf Pro-t néztünk, mert a diagnosztikai cumó a Syno NAS-okban erősen támogatott.

Igazság szerint az 5400-es vagy (power optimized, azaz 5900-as...) diszkeknek nem vagyok a barátja, esetleg archiv célú vagy másodlagos backupnak tudom elképzelni.

Nem megint, még mindíg (lásd a green széria...). :) A sima NAS vagy archive vagy akár "survillance optimized" diszkek 5400-asok már soksok éve. Erre dobták rá a "Pro" verziókat, amik 7200-asok és egyben több diszkes NAS-okba ajánlják őket. Én maradok a Pro-knál.

Az 5400-asok mögött valszin az volt a fő gondolat, hogy a kisebb NAS-ok, 2-4 diszkes otthoniak főleg, eleve jóval gyengébb CPU-val tolják és nehezen hajtanák ki a 7200-es diszkeket. E mellett remekül tudnak vele poziciónálni és extrát kérni a 7200-esekért.

Nekem is szépen ment a Celeronnal a SCSI diszk, meg a SCSI CD írás, az IDE-vel voltak bajok... Szóval azért ott más volt a vezérlő, meg a HBA rész, nem AHCI volt. Biztos van olyan NAS, ahol nem fogod észrevenni a különbséget, de amikor a 700-800MHz-es ARM cpu-ra bízzák a dolgokat, akkor a sok teendő mellett már nem biztos, hogy ki tudja futtatni a diszkeket. Szerencsére egyre több új NAS-ba kerül bármilyen okból (videó átkódolás) erős CPU, ezért ez egyre kevésbé jellemző.

Egy aktuális, valszin már egy pár éves, SATA diszk bőven 180-200MB/sec körüli szekvenciális sebességet tudhat, miközben a régi SCSI diszkjeink erős izgalmi állapotban 40-50MB/sec fölé nehezen mentek (https://www.ibm.com/support/pages/overview-91gb-and-45gb-wide-ultra-scs… 4,5...9,1...) és kellett később az U160 és az U320, hogy szintet lépjenek Ha jól emlékszem, akkor az általálunk egészen sokáig élesben használt 36-73G-s U320-as SCSI diszkek olyan 80-90MB/sec-ig jutottak, úgy, hogy a SCSI vezérlőkön komoly offload van.

Szerk: A kis cpu egészen addig egész jól szokta bírni, amíg egy RAID1 vagy RAID1+0 van, de RAID5-öt szeretnél és számolni kell, akkor hiába a 7200-es, kell a CPU alá.

"120 gigás diszkjeim 2003-4 tájékán már mind 7200-as voltak."

És olyan hangjuk volt, mint egy sugárhajtómű (pláne felpörgéskor). Részemről már jó régóta desktopban és NAS-ban is direkt 5400-asokat használok. A desktopban úgyis másodlagos csak az SSD mellett, úgyhogy tök mindegy, hogy kicsivel lassúbb, mint egy 7200-as, de legalább halkabb. NAS-ban meg -az itthoni felhasználás mellett- a sebesség mindegy, többet számít, hogy kevésbé búgjon.

Nem is tudom mikor vettem utoljára 7200-est. Minek?

10 gigás net van a NAS-ban? Lineáris olvasásnál az 5400-es is telíti a gigabitet, egy darab is.

Kevesebbet fogyaszt, halkabb, talán a csapágy is tovább bírja.

Mai desktop rendszer úgyis használhatatlan HDD-vel, akármilyen RPM-el pörög is.

Azért a fordulatszám önmagában még nem jelent sokat. A nagyobb adatsűrűség miatt sokkal nagyobb adatátviteli sebességet tudnak a régi nagy fordulatszámúakhoz képest is. Legfeljebb az elérési időben lehet különbség, de lehet ez is csak hasonló generációsok közt van, mert a régiekhez képest bevethettek újabb trükköket az újaknál.

IOPS-ban nincs nagyságrendnyi különbség a mai és a régebbi vinyók között - egészen pontosan kisebb a különbség egy 20 évvel ezelőtti jó vinyó és egy mostani között, mint amennyi a ma kapható leglassabb és leggyorsabb között (konstans rpm esetén).

Elérési időben pedig a fordulatszám alsó korlátot ad (félfordulat ideje, ugye), amit azért már 20 éve is elég jól közelítettek a vinyók. Ergó ott sem volt nagy fejlődés.

Ez zseniális válasz:
“Well the higher team contacted me back and informed me that the information I requested about whether or not the WD60EFAX was a SMR or PMR would not be provided to me. They said that information is not disclosed to consumers. LOL. WOW.“

Én használok EFRX és EFAX -ot is, csak hát erről most hallottanm először és nem biztos, hogy  lenne EFAX-om. Az ár tudtommal nem változott.

Irtak erről már 2018-ban is:

A 10 terabájtos Ultrastar esetében például az SMR-es verzió szekvenciális írási sebessége csak a PMR-es modell majd negyede (249 MB/s vs. 68 MB/s). Az SMR-t használó meghajtókat emiatt elsősorban olyan környezetben érdemes alkalmazni, ahol a műveletek túlnyomó többsége olvasás, itt ugyanis kisebb a kompromisszum, 

Emiatt használok Seagate IRonwolfot. Ott nincs ekkora kavar az technológia miatt...

Köszönöm!

Jaja: úgy tűnik a P300 széria 4TB és 6TB disc-ek most SMR-esek. (Kicsit le is vert a víz, mert pont most vettem egy 4TB-os X300-at, pont azért, mert nem akartam SMR-es HDD-t. Szerencsére az X300 nem érintett.) BTW: Toshiba forrás, széria számokkal.

  • MD07ACA – 7,200rm 12TB, 14TB CMR (base of X300 Performance Hard Drive Series branded models
  • MD04 – 7,200rpm – 2, 4, 5, 6TB CMR (base for X300 Performance Hard Drive Series branded models
  • DT02 – 5,400rpm – 4, 6 TB SMR (base for P300 Desktop PC Hard Drive Series 4TB and 6TB branded models)
  • DT01 – 7, 200rpm – 500GB, 1,2,3 TB CMR (base for P300 Desktop PC Hard Drive Series 1/2/3TB branded models)

Régebben emlékeim szerint WD purple használt talán csak SMR-t de azt meg is mondták hogy mire való, és csak arra vedd.

Szomorú, hogy már meg sem mondják.

De ez épp olyan, mint hogy régen a black-re 5 év gari volt, aztán csak három lett, ami régen green volt, abból blue lett, stb.

Még a végén kénytelen leszek mindenhol SSD-re váltani, ami meg szétrohad, de legalább addig gyors. Vagy megvárom az MRAM-ot a következő évezredben :D

A fő bajom az, hogy a wd red  a consumer kategóriában,  de ott  felsőkategóriás NAS lemeznek van beállítva. Igy is árazták. 

Az WDred-EFAX változat  pedig -szerintem- leginkább  a kis otthoni EXT3 , egy vagy két lemezes ,esetleg tükrözött  box-ok  lemeze lett.  

Na ez sunyi, pont a régi EFRX-ek lecserélésén gondolkodtam nagyobb RED-re.

Mi most ami 7/24-es üzemhez NAS-ba ajánlott? 3db van az otthoni NAS-ban.

Mondjuk, "Seagate IronWolf 4TB 64MB 5900rpm SATA 3 ST4000VN008" - erről hogyan deríthető ki biztosan, hogy nem SMR, sőt még flash-t sem használnak semmilyen célra benne? (És a Pro változatnál az árán kívül mi a különbség ehhez képest? - Arra valamilyen tapasztalat, hogy mondjuk WD RED-ek közé RAID-be téve, okozhat-e valamilyen kompatibilitási problémát?)

" - erről hogyan deríthető ki biztosan, hogy nem SMR,

 

Szinten a fentebb linkelt cikk egy masik hozzaszolasaban irtam.

 

https://hup.hu/comment/2441708#comment-2441708

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"A Seagate IronWolf 4-terabájt NAS merevlemeze egy 3,5 hüvelykes merevlemez, amely 5900 ford / perc sebességgel forog, 64 MB beépített gyorsítótárral. A készülék interfésze a SATA 6 Gbps, és párhuzamos mágneses rögzítést, azaz PMR-t is használ, amely segíti a forgó tányérok húzásának csökkentését. Ugyanúgy, mint a nagyobb IronWolf meghajtóknál, a IronWolf NAS 4-Terabyte meghajtónál is megtalálhatóak a cég IronWolf Health Management vagy IHM technológiája, amely támogatja az ASUSTOR, a Synology, Thecus és más NAS eszközöket; ez lehetővé teszi, hogy a merevlemez visszajelzését precízen figyelemmel kísérhesse. Ez a 4 terabájtos IronWolf NAS-merevlemez hároméves garanciával rendelkezik."

https://www.thestreamingblog.com/seagate-ironwolf-4tb-nas-hard-drive-re…

Igazából, a 4TB WD-RED-ek pótlására kerestem merevlemezeket, (még EFRX-ek!) ez a cikk talán meggyőző lehet az SMR elkerülésére..! - Hátha másokat is érdekel a típus... - kipróbálom, mire mennek egymás között. :)

20 éve röhögtünk a DVD játékos, és elektromos csellentyűcske minőségű trehányságokon. Év elején vettem egy Brother címkenyomtatót lidiben, dobozán a felírat szerint: English: Print speed: 2 cm / second

Magyar megfelelője: Nyomtatási sebesség: 2 cm / MÁSODIK.

Apósnak karácsony előtt néztünk egy direkt gagyi-telefont Média-ban: "iLike" xyz csingcsung foscsung valami. Magyar nyelv is volt benne. Nosza átállítottam. Nézem a csengőhang beállításokat: SIM1 csengőhang... valami. SIM1 Masszírozási... Mondom, MI A FASZ?? A mEssage-t mAssage-nak olvasta a félcédulás, és így a ferdítés után Masszírozás lett belőle. Ha van épp kipakolva nyomkodni egy ilyen iLike fostalicska Media-ban, érdemes megnézni, nem én találtam ki.

Szóval az igénytelen fos minőség irányába süllyed minden is. Egyedül csak az ár magas, mert a büdös kapitalisták a sok pénzt azt szeretik.

Akkor nekem a regi 7 eves redekkel ilyen gond nincs, meg vettem purplet az egy doglott helyere, szepen besyncelt.

Szerintem akko gyo... :D Igy most akkor mar seagatet es wd t sem veszunk, marad a folyamatoshiba ami vicces :)

http://karikasostor.hu - Az autentikus zajforrás.

Szerkesztve: 2020. 04. 16., cs - 22:32

sub

megszűnt a konkurencia, nagyjából csak a WD maradt. Úgy geciznek a világgal ahogy csak akarnak. Ld. intel vs Amd 3 évvel ezelőttig.

Melléktörténet: 2 hete rendeltem egy 2TB-os Redet. 1 hét múlva, miután már reklamáltam, meg is jött. Egy recertified példányt kaptam. WD oldala is 2 év garanciát dobott ki, persze 3-al vettem. Jövő héten viszik el. Egyik legnagyobb országos üzlet... Ja, a jótállási jegyen a garancia időtartama: "Wrong arguments for". Érted, a hibaüzenet került oda.

Szóval még jó, hogy nem újat kaptam. WD mostantól feketelistás nálam, már csak amiatt is, ahogy kezelték a hírben taglalt dolgot.

Hát most elgondolkodtam WD Gold kapcsán. Régi Seagate + RED-ből (2-2TB) akartam RAID-1 et csinálni. Kiderült, hogy a Seagate firmware hibás és ezért kidobja a vezérlő. Szóval 3 tervet készítettem, végén a teljes költség látható:

  1. Veszek 2x2TB Ironwolfot és eladom a meglévőket => 23.000 Ft
  2. Veszek 1x2TB Ironwolfot és berakom a RED mellé. Seagatet eladom => 13.000 Ft
  3. Veszek 2x2TB Gold-ot. Ezek újak, de nem boltból veszem, 1 év garanciát kapok rájuk. Nyilván van benne rizikó, de az eladó megbízhatónak látszik. Persze eladnám a meglévőket => 33.000 Ft

Néztem nagyobb Ironwolf-ot (boltból, 3 év garival), azok fajlagosan olcsóbbak, mint a Gold, mégis kicsit gyorsabbak lennének a mostani RED-nél. Viszont többe kerülne akkor is és nekem nem feltétlenül kell több tárhely. Úgy számoltam, hogy a gigabites hálót ki tudnám maxolni sok use-case esetén a Goldokkal, ami nem lenne rossz.

A megbízhatóság az elsődleges szempont, de a sebesség is jól jön. 40 ezernél többet most nem fordítanék erre. Melyik lenne jobb?

Szerkesztve: 2020. 04. 17., p - 07:54

Keresgettem a neten, igazi konkrétumot egy helyen találtam , a 

https://www.smartmontools.org/ticket/1313 -on van egy ticket, ahol  írnak erről a hibáról, 

és ez a smartctl -x -szel lekérdezhető (IDNF-> ID nor found):

10 -- 51 00 00 00 00 cf ae b9 20 40 00  Error: IDNF at LBA = 0xcfaeb920 = 348433436 

illetve a kernel naplóban is ott van: 

6248] blk_update_request: critical target error, dev sdd, sector 3484334368 op 0x1:(WRITE) flags 0x700 phys_seg 2 prio class 0

Ez annyiban jó hír ez a rossz hír, hogy lehet hogy ez "CSAK" egy firmware hiba, ami javítható lesz. 

Illetve azt írják, ha a hdparm TRIM képesnek jelenti a merevlemezt, akkor az SMR, de ez sem  minden tipusra igaz:

hdparm -I shows:
           *    Data Set Management TRIM supported (limit 10 blocks)
           *    Deterministic read ZEROs after TRIM

 

Remélem ezt a hibát javitani lehet. Önmagában az hogy SMR , nem lenne gond, ha lehetne számolni vele.

Kicsit méricskéltem, tényleg támogatja a TRIM-et atz EFAX az EFRX -ben meg nincs ilyen.

 hdparm -I /dev/sda | grep -e TRIM   -e EFAX
        Model Number:       WDC WD60EFAX-68SHWN0
           *    Data Set Management TRIM supported (limit 10 blocks)

Viszont 1 óra alatt nem esett 170 MB/sec alá az írás,(WINDOWS-os fio ) fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randwrite --size=500g --io_size=1500g --blocksize=10m  --iodepth=1 --direct=1 --numjobs=1 --runtime=3600 --group_reporting

fio: this platform does not support process shared mutexes, forcing use of threads. Use the 'thread' option to get rid of this warning.
TEST: (g=0): rw=randwrite, bs=(R) 10.0MiB-10.0MiB, (W) 10.0MiB-10.0MiB, (T) 10.0MiB-10.0MiB, ioengine=windowsaio, iodepth=1
fio-3.13
Starting 1 thread
Jobs: 1 (f=1): [w(1)][0.2%][w=170MiB/s][w=17 IOPS][eta 59m:53s]
Jobs: 1 (f=1): [w(1)][0.4%][w=170MiB/s][w=17 IOPS][eta 59m:47s]

 

Run status group 0 (all jobs):
  WRITE: bw=164MiB/s (172MB/s), 164MiB/s-164MiB/s (172MB/s-172MB/s), io=576GiB (618GB), run=3600056-3600056msec

200 MB blokkméret  ugyanaz,  182 MB/sec 1 óra, 656 GB írás,

 

PS E:\> fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randwrite --size=500g --io_size=1500g --blocksize=200M  --iodepth=1 --direct=1 --numjobs=1 --runtime=3600 --group_reporting
fio: this platform does not support process shared mutexes, forcing use of threads. Use the 'thread' option to get rid of this warning.
TEST: (g=0): rw=randwrite, bs=(R) 200MiB-200MiB, (W) 200MiB-200MiB, (T) 200MiB-200MiB, ioengine=windowsaio, iodepth=1
fio-3.13
Starting 1 thread
Jobs: 1 (f=1): [w(1)][0.2%][w=200MiB/s][w=1 IOPS][eta 59m:53s]
Jobs: 1 (f=1): [w(1)][0.4%][w=200MiB/s][w=1 IOPS][eta 59m:47s]
Jobs: 1 (f=1): [w(1)][0.5%][eta 59m:41s]
Jobs: 1 (f=1): [w(1)][0.7%][w=200MiB/s][w=1 IOPS][eta 59m:35s]

.....

Jobs: 1 (f=1): [w(1)][99.8%][w=200MiB/s][w=1 IOPS][eta 00m:07s]
Jobs: 1 (f=1): [w(1)][100.0%][w=200MiB/s][w=1 IOPS][eta 00m:01s]
Jobs: 1 (f=1): [w(1)][100.0%][w=200MiB/s][w=1 IOPS][eta 00m:00s]

TEST: (groupid=0, jobs=1): err= 0: pid=11780: Fri Apr 17 17:23:10 2020
  write: IOPS=0, BW=174MiB/s (182MB/s)(611GiB/3600129msec)
    slat (usec): min=8294, max=24211, avg=18856.28, stdev=2162.39
    clat (msec): min=1028, max=1469, avg=1132.80, stdev=70.17
     lat (msec): min=1046, max=1491, avg=1151.66, stdev=70.13
    clat percentiles (msec):
     |  1.00th=[ 1062],  5.00th=[ 1070], 10.00th=[ 1083], 20.00th=[ 1083],
     | 30.00th=[ 1099], 40.00th=[ 1099], 50.00th=[ 1099], 60.00th=[ 1116],
     | 70.00th=[ 1133], 80.00th=[ 1167], 90.00th=[ 1267], 95.00th=[ 1284],
     | 99.00th=[ 1334], 99.50th=[ 1351], 99.90th=[ 1401], 99.95th=[ 1418],
     | 99.99th=[ 1469]
   bw (  KiB/s): min=400782, max=409600, per=100.00%, avg=409266.07, stdev=434.69, samples=3125
   iops        : min=    1, max=    2, avg= 1.60, stdev= 0.49, samples=3125
  cpu          : usr=0.75%, sys=0.86%, ctx=0, majf=0, minf=0
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,3126,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=174MiB/s (182MB/s), 174MiB/s-174MiB/s (182MB/s-182MB/s), io=611GiB (656GB), run=3600129-3600129msec
PS E:\>

Én azt találom furának, így olvasgatva a kommenteket, hogy miért a kisebb kapacitású hdd-k esetében használják a technológiát.

Mivel nem értek a témához, magának a rövidítésnek is utána kellett olvasnom, és azt olvastam, hogy ez arra jó, hogy adott felületen több adat férjen el.

Ebből számomra az lenne a logikus, hogy ha nagy méretet akarok, de nem tudok több vagy nagyobb korongot beletenni, akkor ezzel a technológiával meg tudom mégis növelni a kapacitást valamennyivel.

De egy kicsi kapacitású hdd-nél minek? Beletesz egy standard lemezt, és nevetve tudja a szükéges kapacitást. Vagy spórolásból kisebb lemezt tesz bele, mint korábban? Nem tűnik óriási megtakarításnak a korong méretét csökkenteni, de fene tudja. Sok kicsi sokra megy?

Tippre ezzel spórolni fognak: 4 tányér helyett elég lesz 2. A tetején nyűgösebbek a vevők és vastagabban foghat a ceruza is (mehet be a jobb/drágább fej). Ennek ellenére hosszú távon szerintem csak SMR HDD-k lesznek: ahol kell írni is, ott mindent visz majd az SSD, ahol meg főleg olvasni kell, semmi nem fog versenyezni kapacitásban az SMR HDD-kkel. Tippre most az átmeneti folyamat közepén vagyunk.

Egyébként otthonra, átlag Bélának a családi fotóknak, videóknak simán jó az SMR (egyszer írod és sokat olvasod). Tippre még akár szerver oldalon sem para mondjuk egy youtube, photos stb. szolgáltatáshoz (szóval főleg a write once, read a lot jellegű dolgokhoz).

Nem fognak, már rég spórolnak.

És mindenkinek lesz vele gondja, legyen Béla, Józsi, Kata, Sára és valahány név a naptárban, ha Raid-ben kell HDD-t cserélni.

És az a baj, hogy azt mondják jó lesz az neked vagy semmit se.

De szerencsére mit azt itt linket gyűjtő oldalon is már van infó róla melyik milyen, még ha a gyártó rejtegeti is.

A fő kérdés, alkalmas -e RAID 5-6 ba , radz1-2-be. Netán ,  asztali gépbe.   Most nem tudjuk egy NAS lemez jó-e NAS-ba.

A fórumok szerint nem. Wd szerint igen. Van hol azt jvasolják, jó, de ne keverd. 

Néhány fórumon ott a hibaüzenet, hitelesnek tűnik.  (Olyan szektorra akar írni, amit még nem kezel a lemez)

Synology kompatibilitási listáján ott van, de azzal a megjegyzéssel, hogy ne keverd az SMR-t PMR-rel. 

Vicces, hogy azt írják, ne keverd, közben a legtöbb felhasználó nem is hallott még ilyesmiről.

Aki hallott, az is nehéz helyzetben van, mert amikor megrendeled a boltban, nem látod, hogy milyen lesz, amit kapsz. Ha megkaptad, akkor nézheted csak meg szériaszám vagy tesztelés vagy akármi módon.

Olyan szektorra akar írni, amit még nem kezel a lemez

Ennél sokkal rosszabb a helyzet: hiába szántottad be badblocks -wvel, hibát fog dobni: https://github.com/openzfs/zfs/issues/10214

I zeroed the partition, and tried doing the replace / resilver again. It's failed in the same way, at about 26%. The errors are still IDNF.

Az eredeti beszélgetésből, a cikkek egyik szerzőjétől: https://zfsonlinux.topicbox.com/groups/zfs-discuss/Tc81eec4b701e845d-M0…

The thing is: 3 different drives did exactly the same thing

AND they did it after a secure ata erase
AND they did it after the drive had been filled with zeroes
AND they did it after the drives had been trimmed.

AND other people reported the same problem when I popped it up on the WD
forums.

AND WD have been silent - other than the "nice doggy" pat on the head
non-response from the marketing manager.



I've been beating on this for several weeks to see if there's a workaround.

The answer so far is "NO" and WD won't own it - because their drive
tools won't report a fault they won't take the drives back.

Ezért szeretek Amazontól venni dolgokat. Ha nem megy a garanciális időn belül, akkor felhívom őket, elmondom, hogy nem megy, megkérik, hogy küldjem vissza, és vagy cserét küldenek vagy visszaadják a pénzt. És persze választhatom, hogy nem kérek cserét. Vagy megjön a csere, tesztelem, szar, visszaküldöm és visszakapom a zsét.

Nem kell a gyártóval szarakodni, nem tesztelik, hogy az ő eszközeik mit mutatnak és mit nem.

Ezt el tudnám fogadni, ha a nagy kapacitású lemezekbe ugyanezeket a nagy kapacitású tányérokat tennék. De pont, hogy nem.

Tehát most az a (számomra) fura helyzet van, hogy gyártanak nagyobb kapacitású és kisebb kapacitású tányért, és a nagy kapacitásúakból összeszerelnek kis kapacitású terméket, a kis kapacitású tányérokból meg nagy kapacitású terméket.

Egy szavam se lenne, ha a kis kapacitású tányérokból kis, a nagy kapacitású tányérokból nagy termék lenne a végén, vagy ha csak egyfélét gyártanának és mindenbe az kerülne. De pont ez a jelenlegi helyzet elég fura.

És nem lehet, hogy fizikailag ugyanolyan a kisebb és nagyobb kapacitású tányér?

Emlékeim szerint nem csak a flash-nál megszokott megoldás, hogy minőségellenőrzésen osztályozzák, hogy mekkora megbízható kapacitást tud adott példány és aszerint paraméterezik fel a használható méretet. Részben ezért is lehet szórás a sebességekben is.

A több kisebb kapacitású vs kevesetbb nagy kapacitású még az elérési időknél is számíthat. Ha a kisebb kapacitású nem használja ki a teljes fizikai méretet, de 2 helyett 4 van benne, akkor rövidebb fejmozgással elérhető az adat. Máshol meg inkább kevesebb tányér és kisebb fogyasztás számíthat jobban a teljesítménnyel szemben. Szóval más célra, más felállás lehet jobb.

Szerkesztve: 2020. 04. 20., h - 22:49

Szia!

"enterprise sas3" diszket használj, ne ilyen "raid" logó reklámos csoda diszkeket.
Kb 2év múlva már nem lesz kapható az a széria -> WD RED.

        LOGICAL            PHY
512n        512            512
512e     512            4096            ***
4Kn         4096            4096            

Abból is az "512e" verziót (512 szektort emulál, de valójában 4k szektorral dolgozik - kompatibilítás miatt).

Csak a WDx0EFAX sorozatról  van szó. A régivel semmi gond -EFRX, de ez már nem kapható.

 

teljesen felesleges "enterprise sas3" diszket hasznali egy csomo helyen.

Igen,  de: 

SEAGATE 8TB Enterprise Capacity 3.5 7200rpm 256MB SATA3 ST8000NM0055 , bruttó  77900 Ft.

https://ipon.hu/shop/termek/seagate-8tb-enterprise-capacity-35-7200rpm-256mb-sata3-st8000nm0055/1254024?gclid=EAIaIQobChMI9fGznNr56AIVDcKyCh0eTwK_EAQYAiABEgLnaPD_BwE

 

Wd red WD60EFAX (ez  SMR  hdd )  62900 Ft  ,  6TB 

A specifikációjuk szerint ez  a két lemez nem ugyanabban az univerzumban van.

"Enterprise sas3" alatt nem a HP/DELL/EMC féle diszkeket értem - azok aranyárban mozognak.
pl.:
Toshiba MG04sca__ee széria
ez a RED PRO árába kerűl.

Ha meg költséghatékony akarsz maradni legyen SATA3:
Toshiba MD04ACA__ széria.

De itt van egy teljesebb lista:
https://store.supermicro.com/hard-drive/3-5.html?limit=all

nem, meg regebbiek, itt csak arrol volt szo, hogy nem kell rohanni enterpriset venni. (a WAL iras ceph alatt amugy szekvencialis, ergo WALnak pont jo (meg ha picit lassucska is)

 

van igazi 10TB-os SMR lemezunk sok amugy, egy sima mkfs nem tud lefutni rajta. (elso szerias SMR, ~2015-bol)

Az LBA csak annyit jelent, h. nem kell head, track, sector címzést csinálni. Helyette van egy szimpla nagy szám, és az azonosítja az egyedi szektort. Az meg azért ha folytonosan nézed, valószínűleg a lemezen is nagyjából folytatólagosan lesz. Legalábbis így volna logikus, különben folytatólagos adatátvitelnél seek-elne össze-vissza.

Szerintem ezt mióta (drive managed) SMR van, már nem lehet így kijelenteni. A gyártótól függ, hogy miként implementálja.

Itt van például ez, ami határozottan értelmes:
https://blocksandfiles.com/2020/04/15/shingled-drives-have-non-shingled-zones-for-caching-writes/

Ez alapján elképzelhető olyan FW, ami CMR zónákba ír, aztán amikor úgy gondolja, ezeket átmozgatja append only SMR zónákba. Olyan működés is lehet, hogy ott csak akkor ír felül, ha már nagyon betelt.

Ez tényleg már inkább egy SSD, csak más backenddel. Az LBA-nak innentől kezdve semmi jelentősége nincs, az, hogy épp hol van az adatod, nem attól függ, hanem attól, hogy épp hová pottyant, illetve hová mozgatta később a drive.

Kiadtak egy újabb cikket, nem túl sok konkrétummal. Raktárral, meg dobozkákkal magyaráznak. És hát a szokásos "munkaterhelés" . 

https://blog.westerndigital.com/dmsmr-device-managed-shingled-magnetic-recording

 

És hát egy képes vélemény a prohardverről: 

https://prohardver.hu/dl/upc/2020-04/159214_kar.jpg

Nem ájulnék el ettől a teljesítménytől, amit ebben a blogposztban képesek voltak kiizzadni egy hét válságmíting után.

WD blue (ex-trágyagreen-klattyogós széria), 3.5 coll, 2-6TB: CMR/SMR, hol ilyen hol olyan. Gondolom ahogy épp sikerült a gyártás, ugye? Nem.

Generációazonosító kódok meg sehol, cigányputri banda...

Majd ha spec sheet-ben ott lesz feketén fehéren, + idiótabiztos beazonosítási processz, akkor azt mondom talán megtettek valamit a szándékos átverési kísérletük tompítására. Azért remélem class action lawsuit-ban kifizetnek pár milliárdot... a hájfejű brooklyn-i ügyvédhaveroknak.

Nemrég vettem pár (tízes nagyságrendű) merevlemezt, így kiszámoltam mindegyikre a kapacitás/ár mutatót. Érdekes módon nem az SMR-es diszkek jöttek ki nyerésre (szerencsére, mert ha tudtam volna, hogy SMR-esek, biztos nem olyat veszek).

Ezek után csak egy magyarázat van: a WD nagyobb profittal értékesítette ezeket a diszkeket, ráadásul át is baszta a usereit.

Ezért lakolnia kell!! :)

Blogolt wd : 

https://blog.westerndigital.com/wd-red-nas-drives

A tipikus kisvállalati / otthoni NAS-munkaterhelések adatintenzitása szakaszos, így elegendő tétlen idő marad a DMSMR-meghajtók számára a háttér-adatkezelési feladatok elvégzéséhez és az optimális teljesítmény-élmény folytatásához a felhasználók számára. 

Értetlen népség.Ha előre szóltak volna , csak összezavarodtok. Pedig ott volt minden eddig is a specifikációbanan.

Végigolvasgatva egy csomó fórumot, úgy néz ki vegyesen nem ajánlott (CMR+SMR), raid 5-6 z1-2 be főleg.  De Synology kompatibilitási lista szerint nem keverve -és nem felrázva jók.   Többet nem tudni, majd csak készülnek részleesebb  tesztek idővel.

 Nem ide tartozik, egész más téma:

Visszahoztam ezt a rovarirtót, nem ér semmit.
Hogyan használta, uram ?
Beletöltöttem a tartályba és lepumpáltam vele a legyeket. Meghiztak.
ÁHÁ, na itt a baj. Nem olvasta el a specifikációt.
Tehát, fog egy legyet, a hüvelyk és mutatóujja közé, óvatosan megnyomja a potrohát, a légy kitátja a száját   Ön beleönti a mérget és kész.
Ennyi erővel agyon is csaphatom.
Agyoncsapni?  Az is jó!

Nem is tudom miért jutott ez eszembe..

 

 

Slightly related: epp most kezdett sipolni a NAS-om a spajzban, hogy az egyik HDD megdoglott benne. Volt benne egy 1x WD Blue, 2x Green, 1x Red. Tippeljetek, melyik. :D

Kipróbáltam 3 db  6TB-os hdd:   WDC WD60EFAX-68SHWN0,  Freenas, RAIDZ1 ,  nem keverve , nem rázva csak smr: 

Ha  csak SMR van a tömbben akkor megy a rebuid, resilver (Available Space:  546,46MiB   (96% used, -ez  kb 10 TB )  

 pool: T3
 state: ONLINE
  scan: scrub repaired 0 in 0 days 13:46:00 with 0 errors on Wed Apr 29 14:23:33 2020
config
NAME                                            STATE     READ WRITE CKSUM
        T3                                              ONLINE       0     0     0
          raidz1-0                                      ONLINE       0     0     0
            gptid/23be43d1-87ba-11ea-a1de-50465d57ccd0  ONLINE       0     0     0
            gptid/da5573ea-8729-11ea-b2c1-50465d57ccd0  ONLINE       0     0     0
            gptid/da5eebb0-8729-11ea-b2c1-50465d57ccd0  ONLINE       0     0     0
errors: No known data errors

SMR és CMR vegyesen : Toshiba + wd EFAX, szintén ZFS.

Na ez nem megy, 40  %-nál újra kezdi a rebuild-et.  ugyanazzal a hibával mint a https://www.smartmontools.org/ticket/1313?cversion=0&cnum_hist=13 -on:

IDNF error  és annyi.

Frankó. AKkor lehet, hogy mégsem admom el az itthoni 4x5TB wd redet, azok legalább még mennek.

Lassan  készülnek az SMR  tesztek :

Mixed rebuild: (a video-k  végén a rebuild idők táblázata)

https://www.youtube.com/watch?v=sjzoSwR6AYA

Rebuild:

https://www.youtube.com/watch?v=0PhvXPVH-qE

 

Synology viszont kivette a kompatibilitási listából kb. két hete és inkompatibilisnek jelölte az összes EFAX-ot.

https://www.synology.com/hu-hu/compatibility?search_by=category&category=hdds_no_ssd_trim&filter_brand=Western%20Digital&filter_class=NAS&p=1

 

Kompatibilis modellek
  • Egyik típus sem kompatibilis ezzel az eszközzel.
Az SMR típusú meghajtók teljesítményjellemzői miatt ez a típus kizárólag kis munkaterhelésű környezetekben ideális. Folyamatos írási terhelés esetén teljesítménycsökkenés jelentkezhet. További információkért olvassa el a gyakori kérdéseket.