ZFS rosszul berakott diszk

ZFS Fan Club

Sajnos amikor be akartam tenni egy spare diszket a poolba elrontottam és kimaradt a spare paraméter. Sikerült a zpool add pool spare device helyett zpool add pool devide-t írni. Ettől bekerült felső szintre és már nem tudom kivenni, mert ONLINE

        NAME                                          STATE     READ WRITE CKSUM
        bckpstore                                     ONLINE       0     0     0
          raidz2-0                                    ONLINE       0     0     0
            ata-WDC_WD40EFZX-68AWUN0_WD-WX12D8003F7C  ONLINE       0     0     0
            ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N5KDAH2E  ONLINE       0     0     0
            ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N5KDALZF  ONLINE       0     0     0
            ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N6CYHHKR  ONLINE       0     0     0
            ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N6CYHS6N  ONLINE       0     0     0
            ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N6EXR12J  ONLINE       0     0     0
          ata-WDC_WD40EFZX-68AWUN0_WD-WX12D8003SVR    ONLINE       0     0     0
 

Ettől persze értelmét veszítette a raidz2 a poolban.

Van valakinek ötlete arra, hogy a pool lebontásán és újra csinálásán kívül hogyan változtathatom spare-re a diszket?

  • 1084 megtekintés

( vasla_ | 2021. 08. 26., cs – 14:19 )

Én úgy tudom, hogy csak újraszervezéssel lehet.  Lemezzel bővítést  sem lehet , (csak vdev-vel) talán egyszer majd ..  Ez azért jó lenne.

https://blog.claryel.hu

( willy v | 2021. 08. 26., cs – 14:20 )

Mivel nem igazán volt beszédes a kérdés, feltételezve hogy ez openzfs:

Nincs más lehetőséged, mint az újragyártás, mivel az olyan pool-ok ami raidz device-t tartalmaznak nem támogatottak top lvl vdev eltávolítására (ha nem raidz lenne akkor lenne megoldás). 

Még ha csak replikálna akkor bátrabb lennék - például fizikailag lehúzni és utána megbeszélni vele, hogy ez nem is lesz többé. Attól tartok, hogy stripe-olni kezdett az új diszk és a régi raidz2 között.

A Solarisban már van ilyen feature ami nekem kellene, de nem tudom, hogy a Linux-os OpenZfs-be is átszivárgott-e már.
https://blogs.oracle.com/solaris/post/oracle-solaris-zfs-device-removal

Úgy látom, hogy 2016 óta van rá kezdeményezés. (https://github.com/openzfs/openzfs/pull/251)

( tompos v | 2021. 08. 26., cs – 15:59 )

zpool remove Megfeleloen uj zfs kell hozza, talan 0.8.x

( Elbandi v | 2021. 08. 27., p – 11:16 )

/flame

ez ugye meg nem production ready zfs? bar teny hogy egy rm-mel is labol loheted magad, es az mar p.ready :)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

A raidz2 diszkenkénti bővítése szerintem is kulcs funkció lenne. Várom már, hogy mikor készül el. Mivel ilyen még nincs nem is ez volt a cél csak egy spare diszket akartam hozzátenni a poolhoz. Ez a tényleg teljesen értelmetlen állapot úgy állt elő, hogy kimaradt a spare paraméter. A user hibát persze nem lehet számon kérni egy rendszertől, egy warningot azért ért volna. Örömmel látom, hogy az újabb verzióban már kell a force ha hülyeséget készülsz csinálni.

Normális helyen egy productiont érintő parancs kiadása előtt minimum kapsz egy diffet, hogy mi volt-mi lesz, tényleg ezt akarod-e. Jobb esetben kötelező egy másik ember általi review is. Ilyen téren az ingyenes cuccok 99%-a szar, és a ZFS-nél ez főleg óriási probléma, ahogy a téma is mutatja.

Most erre mit mondjak, miért kellene kötelezővé tenni a dry run-t? Szívjon mindenki az inkompatibilitással, csak ne történjen véletlen emberi hiba? Ettől lenne valami professzionális?

A nevetésedet meg nem értem, semmilyen példát nem hozol ami cáfolható lenne, játszod a misztikust, nem mondasz részleteket, majd feltételezed, hogy úgy szóltam le valamit, hogy nincs ismeretem róla... 

Nem pontosan értem mit akarsz ezzel de alapvetően ahol a raidz-t használják ott ez nem kérdés mert vagy portszegény a megoldás, olcsó megoldásra törekszenek vagy csak rosszul van szervezve. Alapvetően nem így szerveznek diszkeket, és pool-okat ahogy a példába van. Hogy kellene máshogy? ha muszáj mindenképp raidz, akkor inkább már Ndb raidz1 és akkor ilyen gond nincs. De ami teljesen biztos, hogy aki 200TB tömböt csinál nem 1 db raidz2 -be szervezi. Ugye. Tehát valójában mi a gondod?

( hnsz2002 v | 2021. 08. 27., p – 15:33 )

Ahh, az agyonajnározott istenített ZFS.... :D (Bocsi a flame-ért)

Én is szoptam anno hasonlókkal, utána hajítottam ki az egyetlen ZFS-t (ami ráadásul nem is teljesített jól), és maradtam a jőöreg mdraid+lvm kombónál.

"Sose a gép a hülye."

Én se nagyon szeretnék olyan rendszert uzemeltetni, amit egy rosszul begepelt parancssal visszafordithatatlan allapotba lohetek, csak azert mert faszul, atgondolatlanul lett kialakitva a mukodtetese. Az oke, ha nem ertek valamihez olyan melysegeben, hogy minden opciora pontosan tudjam, hogyan fog viselkedni az adott rendszer, mert olyan ember nincs a foldon, aki mindent 100%-osan kepes atlatni, de hogy a fajlrendszert programozok, es a karbantartoi, felhasznaloi kozossege kozul senki sem vette a lapot eddig egy ilyen bagatell modon elkovetketo problema kikuszobolesere, az azt jelzi, hogy lesznek itt meg varatlan meglepetesek. Produktiv kornyezetben pedig ez ilyen megoldas eletveszelyes.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Valahogy azert csak megcsinalta, valahogy csak produktiv kornyezetbe kerult egy olyan rendszer, amivel ez a malor elkovetodott, nem? Vajon mit rejthet még egy ilyen modon kiadott rendszer, amit majd valaki hasonlo modon fog, a sajat kárán megtapasztalni?

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

 felhasznaloi kozossege kozul senki sem vette a lapot eddig egy ilyen bagatell modon elkovetketo problema kikuszobolesere, az azt jelzi, hogy lesznek itt meg varatlan meglepetes

Javitották, szóval nem lehet alacsonyabb redundanciája a poolnak a pool módositása miatt. A kérdező által kiadott parancs ezt már nem engedi meg. Ezt plusz opció hozzáadásával lehet megtenni -f , jóváhagyással.

-f

Kényszeríti a vdev  használatát ,  ha  ütköző replikációs szintet adnak meg. Nem minden eszköz írható felül ilyen módon.

https://blog.claryel.hu

..ahelyett, hogy már kezdettől fogva hasznaltuk volna azt, amit eleve arra terveztek, ugye kedves, kiserletezo kedvu kollegaim?!. :)

 

Hát igen, maradjunk a bevált "monolit" megoldásoknál:)

https://www.youtube.com/watch?v=H2uHBhKTSe0&list=RDCMUC3gNmTGu-TTbFPpfSs5kNkg&index=1

https://blog.claryel.hu

Elég elszomorító az a szakmaiatlan hozzáállás amit bemutatsz. Mindig vannak hibák, mindig vannak félresikerült munkák. (megjegyzés, szerintem főleg ebből élünk).  Gondolom úgy érzed, te vagy az egyetlen ember aki mindent mindig elsőre jól csinál. Örülök neki, nem mindenki ilyen tökéletes. 

Mi volt itt tökéletlen?

Alanyunk "0.7.5"-ös verziót használ, amely ugyan még egy frissített verzió, és semmilyen stabilitási probléma nincs vele, de mivel erősen a a fejlesztés időszakában volt ezért abszolút nem volt szempont a valószínűtlen akaratlan módosítások.

Megjegyzés: Egyébként az előállt konfiguráció teljesen használható, sőt elvetemült helyzetben még lehet jó megoldás is semmilyen adat nem ment tönkre, csak épp degradálódott a tömb biztonsága. 

Mivel mindent lehet jobbá tenni, az újabb verziókban a valószínűsíthető akaratlan konfigurációkat egy "-f" -el meg kell erősíteni. Attól tartok, ez az igazán elszántakat továbbra sem fogja attól megakadályozni, hogy elkövessék ezt a hibát, de legalább a vétlen elgépeléstől véd. 

Egyáltalán miért reagálok akkora égbekiáltó baromságra, mikor egy szakmai portálon egy elkövetett emberi hibát lehetővé tevő régi konfigurációt szapulnak? Azért, mert ez a baromság olyan irányba vezet amit nagyon nem szeretnék. Bemutatom jó? Itt egy bugyuta hasonlat a baromságodra:

bootdisk képmentése:

dd if=/mnt/mentesek/sdaelozokep.img of=/dev/sda bs=4k

^H^H^H 

basszus megcseréltem az o-t az i-vel trehány szoftver miért nem igényli hogy kiírjam inputfile outputfile utolsó szar szoftver ugye?

Igen, itt sajnos a kár azonnali, és nem csak kényelmetlenség, valahogy MÉG SEM szeretném, hogy ki kelljen írni.

Gratulálok egyébként.

Én megsertodni? :) nem az en szivem csucske ez a dolog. Szamodra mennyire szimpatikus egy olyan vilagban dolgozni, ahol a rajongas felulir mindenfele objektivitast?!..

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Hibás feltételezésből indulsz ki, leszarom hogy mit gondolsz a ZFS-ről. Nekem azzal van bajom, hogy a  következő visítások jöttek elő:

- Hogy a fenébe nem volt már eredetileg jó a rendszerben, miért kell erre várni a következő verziókig?

- Egy ilyen hype-olt rendszer lehetne azonnal tökéletes,

- Mi derülhet még ki amit nem is tudunk?

(sőt másik megjegyzésben mástól:)

- miért nem default a "-n"

Nem akarok olyan ZFS felhasználókat, sőt olyan system adminokat sem akik így gondolkodnak, de nem használnak ZFS-t, mert akkor a világ rossz irányba tart.  Ezért kritizálhatsz, ha úgy gondolod ez baromság, de azért mert úgy gondolod a ZFS-t védem azzal nagyon el vagy tévedve. Lehet nem ment át.

Az a fő probléma, hogy bármivel a 22-es csapdájába kerülsz. Csak úgy tudsz valamivel tapasztalatot szerezni, hogy azt élesben használtad, ehhez viszont kell egy lehetőség, ahol az már megy vagy mondjuk úgy bevállalják. Én anno talán még az elsők között (2007-2009 körül valahogy, de lehet korábban) próbálkoztam élesben FreeBSD-n ZFS-sel. Volt ott SSD-vel ZIL meg minden volt, de onnantól, hogy nem tudtam bővíteni diszkkel, meg nem volt mindíg egyértelmű, maradt szintén az mdadm+LVM vagy jobb esetben valamilyen épkézláb hw raid. Ezen felül néhány kivételes esetben iSCSI vagy FC-vel elért SAN, de persze mivel hazai viszonylat, ezért egy dobozos. :)

Az mdadm+LVM, illetve a hw raid + LVM (adott rendszer LVM-et vár el, meg nem biztos, hogy a raid vezérlőn akarok annyi és olyan logikai kötetet) roppant jól és megbízhatóan megy. Gondolom a ZFS hasonlóan jó, hogy ha a fix 45-60 diszkes óriásdobozt teleszórják diszkkel és az úgy kész van. (Igen, volt valamilyen thin provisioning opció, akkor később is lehetett bele diszket tenni.) Volt azt hiszem a SUN -nak az X4500-as. és mostanában a Supermicro csinál sokdiszkes házikós megoldást.

Ide kapcsolódik egy ismerős CEPH-es szívása, miszerint 2x borult be neki úgy, hogy sokórás leállás volt, és nem is tudta maga összelapátolni, pedig elég korán elkezdte használni. Az egyik esetben talán mentésből kellett visszahoznia dolgokat, és ha jól rémlik kiderült, hogy az újabb verziók már azért stabilabbak. Nem hozta meg hozzá a kedvem, ahogy az sem, hogy minimum 2+3 fizikai gép kell emlékeim szerint.

Egy vállalati környezetben elég nehéz a "jajj fú ez jó lesz" dolgokra piffpuff ráindulni, mert nem lesz (mély) szakértelem vagy támogatás hozzá. Az nagyon jó, hogy valamit összeraksz egy-két tesztgéppel és alapvetően működik, de üzemeltetési tapasztalatot az nem ad.

Ebben benne van a veszélye, hogy valaki beleragad adott technikába és kiöregszik, de ennek a másik oldala, hogy igazán idő nincs csak úgy próbálkozgatni, hacsak az adott projekten belül vagy munkahelyen nem biztosítják. Igen, már volt topik az önképzésről, ott is kifejtettem, hogy rommá képezheted magad kiváncsiságból. Ez viszont legfeljebb annyi, hogy láttál már olyat, összeraktad, esetleg 1-2 hibát szimuláltál, és mondjuk egy hobbiprojekt alatt ment. Remek példa erre, hogy egyszer egy távoli galaxisban teljesen ráindultak a Proxmox nevű történetre. Az, hogy ugyanúgy KVM, mint a meglévő másik megoldás (speciel néhány ok miatt a Proxmox megoldásában elvben jobb lenne, de ezt csak később derítettem ki, mikor komolyan kezdtek vele foglalkozni, az említett esetben nem én telepítettem), az nem zavarta őket. "Felpattintottak" egy gépre Proxmoxot, mindenkinek mindent el kellett dobnia emiatt, és utána 4-5 hónappal kérdeztem rá, hogy kell-e még a gép, vagy egyéb célra elhasználható-e. A válasz az volt, hogy persze, mert végülis nem jutottak tovább...

El kell keserítselek a dolgok nem így szivárognak enterprise-ba. Van ott persze R&D meg integration engineering is. De a legtöbb megoldást valamilyen előző üzlet/megállapodás szüli (vagy a cégnek van már élő szerződése, vagy John Doe a cégnél ismeri Bob Doe-t a másik cégnél vagy netán ott dolgozott). A maradék az kényszerből lesz alkalmazva. De olyan enterprise ami nem kiszervezve üzemeltet tárolót az egy ZFS jellegű megoldást, a gyártói támogatáson túl  körülszabja különféle "tooling"-al ami megfelel a szabályzatának, valamint az engedélyezési rendszerének és adja azt az a katyvaszt, amely még mélyebbre löki az egész technológiát (ezt csinálja az integration engineer). 
Ismerek olyan történetet, hogy maga a technológia még nem is létezik az adott gyártónál, dolgoznak valamin ami hasonló lenne, de hát John meg Bob együtt ebédelt, és hát John mondta mi kéne neki, Bob meg mondta hogy az majdnem kész, ezért az a röpke 3 év ami eltelik a bevezetésre, úgy hogy még a termék (amit a világ fog kajálni) a vevő egyedi baromságait is elkezdi implementálni.

Szerencsére ez picit változóban van az utóbbi 10 évben, mivel nem egyszer startup-ok nyernek teret bizonyos technológiákra támaszkodva, ahol ez nem "enterprise" struktúrában fejlődik, és a többnyire káros elkerülhetetlen szart (tooling) csak később adják hozzá, mikor nélkülözhetetlenné válik.

Ezzel persze nem azt akarom mondani, hogy a change management úgy ahogy van baromság, de ettől még amit sikerült megoldásokat látnom az mind kisebb nagyobb sikerrel utánozta az eredeti célt (követhető és visszaállítható módosítások), ellenben sok egyéb baromságot sikerül azért köré tenni, amit "csak úgy" csinálnak mert jó.

Emellett mindennek megvan a saját maga sztenderd fejlődési üteme, mikor a technológiára épülve enterprise level termékek jelennek meg az jó jel. Jelenleg a OpenZFS ezzel még nem áll jól és nem is ez a baj vele hanem 

1, integrációt nehezíti a licencelése (ez az egyik legnagyobb gát)

2, még mindig sok erőforrást eszik (nem valószínű hogy ez változni fog)

3, még mindig sok tudás kell hozzá, hogy általános céllal alkalmazható legyen 

4, még mindig vannak hátrányai bizonyos terhelési szituációkban 

 

Ettől még mindig igaz, hogy a 

1, integrált teljes management (diszk, cache, volume, filesystem, quota, admin permission, point in time recovery)

2, ismerek olyan helyet ahol éves szinten dollármilliókat mentenek meg a beépített tömörítéssel, és a helyi SED drive ok felszaporodása előtt a beépített titkosítással. 

3, ha egy bizonyos használatra ki lett próbálva, azt stabilan hozza. Márpedig pont ez amit egy enterprise tesz.

 

Lehet nem szeretni egy technológiát, ez inkább ízlés és habitus kérdése. Ezzel semmi gond nincs. A gond azzal van, amikor a fejlődés negatívumként van beállítva. De szerintem sokkal nagyobb gond, hogy a gyakorlatlanság és az emberi hibát a szoftvernek a rovására írja egy rendszeradmin és elvárja, hogy a problémát a szoftver oldja meg helyette és ne engedje őt hibázni, találja ki mit akar, és az miért rossz. 

De hát ez logikus. Ha a sok évvel ezelőtti 0.75 -ös verzióban lehetséges egy ilyen dolog, ugyan javitották, de az új verzióban viszont még más, nagyobb hibák lehetnek. A következő kiadás meg lényegében fölösleges, még több és más nagyobb hibák is rejtőzködhetnek majd. Mi a garancia,  hogy nem így lesz ?  

https://blog.claryel.hu

( vasla_ | 2021. 08. 29., v – 06:21 )

Szerkesztve: 2021. 08. 29., v – 06:27

https://github.com/openzfs/zfs/pull/12225

zpool attach POOL raidzP-N NEW_DEVICE 

Az ideiben  már nem  , de a következő  "nagy" ZFS kiadásban várható az attach, vagyis a raidz bővitése lemezzel.

 

zpool-attach.8:

NAME
     zpool-attach — attach new device to existing ZFS vdev

SYNOPSIS
     zpool attach [-fsw] [-o property=value] pool device new_device

DESCRIPTION
     Attaches new_device to the existing device.  The behavior differs depend‐
     ing on if the existing device is a RAIDZ device, or a mirror/plain
     device.

     If the existing device is a mirror or plain device ...

     If the existing device is a RAIDZ device (e.g. specified as "raidz2-0"),
     the new device will become part of that RAIDZ group.  A "raidz expansion"
     will be initiated, and the new device will contribute additional space to
     the RAIDZ group once the expansion completes.  The expansion entails
     reading all allocated space from existing disks in the RAIDZ group, and
     rewriting it to the new disks in the RAIDZ group (including the newly
     added device).  Its progress can be monitored with zpool status.

https://blog.claryel.hu

( cspguy v | 2021. 08. 29., v – 19:29 )

Írtam mailt, ha tudok segíteni, keress meg.