David Stewart - az Intel OpenSolaris munkacsoportjának vezetője - arról ír blogjában, hogy két nagyon érdekes, az Intel Atom processzorok támogatásával kapcsolatos változtatás került bele mostanság az OpenSolaris kódbázisába. Az egyik változtatás a Atom teljesítmény számlálók (performance counters), a másik pedig a MOVBE utasítás támogatásának megjelenése.
"Szóval, mostantól az OpenSolaris kernel nem csak azokat a feltétlenül szükséges darabokat tartalmazza, amelyek ahhoz kellenek, hogy egy Intel Atom-alapú platformon futni tudjon (valójában ezek hónapokkal ezelőtt elkészültek), hanem azokat is, amelyek szükségesek ahhoz, hogy szoftvert és driver-t lehessen optimalizálni az Atom-ra."
A blogbejegyzés itt olvasható.
(A linkért köszönet vOrOn olvasónknak!)
- A hozzászóláshoz be kell jelentkezni
- 1820 megtekintés
Hozzászólások
- A hozzászóláshoz be kell jelentkezni
Mit? Azt, hogy elmegy januártól Alan Cox a Red Hat-tól az Intelhez, ahol szintén Linux-szal fog foglalkozni s ezért elfelejtük hirtelen, hogy ő volt a második Linux kernelhacker Linus mögött és hogy 17 évig Linux-ot fejlesztett? Vagy mi az a borzasztó nagy logika, ami a kijelentésed mögött áll?
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nem lennék meglepve, ha egy új, Atom procis Sun NAS jönne ki fél éven belül :)
- A hozzászóláshoz be kell jelentkezni
Na de mi számolná a checksumot a ZFS-hez?
- A hozzászóláshoz be kell jelentkezni
ilyen bonyolult kerdest itt ne tegyel fel :-)
amugymeg, ezt ugy mondod, mintha a zfs checksumming rossz dolog lenne.
- A hozzászóláshoz be kell jelentkezni
Az attól függ.
Vannak itt például sima dd-vel kapott eredmények, két darab Areca 12 portos SATA RAID vackon, egyenként 12 db 7k2 RPM-es SATA diszkekkel, két CPU-s Opteron (nem mai darab) gépen:
2*12 diszk HW RAID6-128k, WB cache, stripe, zil_disabled:
R: 8589934592 bytes transferred in 36.219417 secs (237163802 bytes/sec)
W: 8589934592 bytes transferred in 16.444749 secs (522351210 bytes/sec)
2*12 diszk HW RAID6-128k, WB cache, stripe, checksum=off zil_disabled:
R: 8589934592 bytes transferred in 35.450002 secs (242311259 bytes/sec)
W: 8589934592 bytes transferred in 12.846934 secs (668636932 bytes/sec)
És mielőtt megkérdeznéd, hogy miért teszem a két kontrolleren egyesével RAID6-ba a diszkeket, és azokat ZFS-sel stripe-olom, ahelyett, hogy passthru (vagy RAID0) diszkeken csinálnék RAIDZ2-őt:
24 diszk pass through, WB cache, raidz2, diszkekre zil_disabled:
R: 8589934592 bytes transferred in 50.697473 secs (169435163 bytes/sec)
W: 8589934592 bytes transferred in 44.321138 secs (193811238 bytes/sec)
Bár itt nem látszik, ezeken a régebbi CPU-kon a checksum azért érezhető system idő növekedést jelentett. És egy stripe-olt HW RAID6-nál nincs is igazából jelentősége (főleg, ha az adatok is olyanok).
Nem tudom egyébként miért érzed ezt, a checksumozás jó, bár igazából értelme akkor lenne, ha rendszeresen csinálna kieső időben scrubbingot.
Épp a múlt héten jártam úgy, hogy egy ritkán írt RAID1 teljesen egészségesnek tűnt, majd mikor újra akartam szinkronizálni az egyik lemezt, kiderült, hogy alig működik.
- A hozzászóláshoz be kell jelentkezni
Mint mindig, az eredmenyeid most is nagyon erdekesek, de egy kicsit keveslem 24 diszkre azt a raidz2-t.. vagy tenyleg valami regi csotrogany hardver lenne?
- A hozzászóláshoz be kell jelentkezni
Mai szemmel nézve az:
CPU: AMD Opteron(tm) Processor 246 (2009.27-MHz K8-class CPU)
FreeBSD -CURRENT amúgy, és a raidz2 elég jelentős CPU időt vitt (semmi extra, csak toppal néztem, "szemre").
Csak pár percet szórakoztam vele, azt akartam kideríteni, hogy melyik módszer felelne meg nekem a legjobban. A hardveres RAID6 plusz ezek stripe-olva adta a legjobb eredményt.
Próbáltam 8 diszkenként raidz2-őt és azokat stripe-olni, de azt nem találom a feljegyzésben, azaz minden bizonnyal nem volt érdemi változás, vagy annyira csapnivaló volt, hogy fel sem írtam (az előbbi valószínűbb).
Neked mások a tapasztalataid?
- A hozzászóláshoz be kell jelentkezni
200MB/sec alatti eredmenyeid vannak, 500-at biztosan lattam ennyi diszkbol raidz2-vel. Az elso generacios X4500 volt, nem sokkal jobb CPU-val, mint a tied. Vagy eppen sokkal jobb? Nem tudom. A CPU azokon is hamar 100-on volt... Ujabb hardvereken meg aztan teljesen mindegy. Meg az is lehet, hogy FreeBSD-n mashogy csinalodik. Az biztos, hogy a cksum eroforrasba kerul, csak nem mindegy, mennyibe. Meg igazad van, hogy a rendszeres scrubbal lenne ertelme, sajnos meg sok penzbe kerulo storage eszkozoknel is csak olyat lattam, hogy adott idonkent (1 het/1 honap/stb) consistency check-et vegez. Ezt be tudja rakni az ember cron-ba is. Az idealis az lenne, ha folyamatosan ellenorizgetne magat, par blokkot innen, par blokkot onnan, stb... idealis esetben valami LRU szerint, azt ellenorizni, amit regen hasznaltunk..
- A hozzászóláshoz be kell jelentkezni
Hát a nem sokkal jobbal azért vitatkoznék, azokban mintha 2,8-as CPU-k lettek volna, mindenesetre DC-k, és két darab. Más generáció.
Én eddig szerencsére csak olyan helyen találkoztam adatmódosulással (ZFS-sel checksum error), ahol a diszk már amúgy is read errorokat dobott, azaz a RAID is kivette (volna) a tömbből, vagy legalábbis sipákolt volna új diszkért.
A cronos scrubbal két gondom van:
- nem éppen üresjárati időben történik (bár lehet neki limitet adni, de az koránt sem ugyanaz, ráadásul nincs külön a resilveringre, így ha nagyon alacsonyra veszem, kihullik az összes diszkem, mire egyet újraépít). Korrektebb lenne, ha akár egy időablak megadásával (amikor nem várható nagy IO) az adott időben beütemezné teljes sebességgel, ha pedig közben jönne más kérés is, akkor kis időre félretenné.
- csak a használt területet nézi végig, így ha például a diszkek egy megadott része nagyobb eséllyel hibásodik meg, és azt nem használja a ZFS, majd egyszer csak ráír (ami sikeres, viszont a visszaolvasás már problémás, ilyet is láttam nemrég), csókot inthet az adatoknak, hiába van meg visszaolvashatatlanul 2 (vagy akár három) lemezen
Szerintem lesz majd ilyen is, nem érzem nagy kihívásnak megcsinálni, de mindenképpen hasznos.
- A hozzászóláshoz be kell jelentkezni
"És egy stripe-olt HW RAID6-nál nincs is igazából jelentősége [a zfs checksum-nak]"
En azert latok nehany lehetoseget:
- Ha hibas lesz a checksum, legalabb tudsz rola hogy itt valami gaz van.
- Ha nincs redundancia, akkor igaz a hibas blokk hibas marad, de legalabb tudod melyik file serult.
- A fontosabb adatokra csinalhatsz redundanciat a copies property-vel.
"a checksumozás jó, bár igazából értelme akkor lenne, ha rendszeresen csinálna kieső időben scrubbingot."
Ez kicsit ugy hangzik mintha nem lenne zpool scrub parancs.
- A hozzászóláshoz be kell jelentkezni
(főleg, ha az adatok is olyanok), ezt se felejtsd le. És azt se, amit alatta írtam.
"Ez kicsit ugy hangzik mintha nem lenne zpool scrub parancs."
Elolvastad a többit is esetleg?
- A hozzászóláshoz be kell jelentkezni
Igen, elolvastam mindent, azert fogalmaztam igy.
Ha nem tudnam hogy letezik zpool scrub, akkor a hozzaszolasodbol azt szurnem le, hogy a zfs nem tud scrubbing-ot.
- A hozzászóláshoz be kell jelentkezni
"A cronos scrubbal két gondom van:" (és az alatta lévők)
A cron egy program, amely időzített futtatásra alkalmas. De vajon mi lehet a scrub? Egy olyan funkció, amelyet nem tud a ZFS?
Feltételes módot sehol sem látok, azaz nem csak egy elméleti lehetőségről beszélgettünk.
- A hozzászóláshoz be kell jelentkezni