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
Hozzászólások
É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.
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
https://www.reddit.com/r/zfs/comments/gd4fkp/removing_device_added_as_v…
A ZFS ezer örömmel elkezdett replikálni az új diszkedre, és úgy tűnik, nem lehet megbeszélni vele, hogy szívja vissza onnan az adatokat.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
zpool remove Megfeleloen uj zfs kell hozza, talan 0.8.x
- A hozzászóláshoz be kell jelentkezni
Köszönöm ez reménykeltő.
Ez egy szép régi linux 0.7.5 zfs-el. Egyel több indok az upgrade-re.
- A hozzászóláshoz be kell jelentkezni
Semmi értelme az upgrade-nek... az információ amit kaptál nem felel meg a valóságnak, ahogy írtam fent ha a poolban van raidz akkor nem működik a a device_removal (openzfs)
- A hozzászóláshoz be kell jelentkezni
Hát ez nem egy bolondbiztos megoldas az tény.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
Kipróbáltam, valóban:
cannot remove loop111: invalid config; all top-level vdevs must have the same sector size and not be raidz.
- A hozzászóláshoz be kell jelentkezni
Köszönöm.
Akkor marad a filerendszer átküldése egy másik poolba és újracsinálás - vehetek egy nagy diszket - ráadásul a művelet alatt csak egy diszken lesznek az adatok (kb az lesz a helyzet, mint most csak legalább elmúlik az egy diszkes állapot a végén).
- A hozzászóláshoz be kell jelentkezni
Azért lehet nem feltétlenül kell egy nagy diszk ehhez, persze ez annak a kérdése mi fér még bele a részedről, az upgrade majd nem ártana azért, mert ezt a malőrt innentől majd csak -f megadásával lehet elkövetni.
- A hozzászóláshoz be kell jelentkezni
Mindenképpen kell diszk, mert a pool újra létrehozásakor valahova tenni kell az adatot. Több kicsinek meg nincs elég sata portom.
Az upgrade-ben igazad van, előbb-utóbb úgyis meg kell csinálni. Most legalább kaptam motivációt is.
- A hozzászóláshoz be kell jelentkezni
Esetedben az USB is megoldást adna, persze mondom az a kérdés meddig mehetsz el. Én pl zfs send-el elküldeném valami cloudba a streamet majd vissza (max 20TB forgalom), de ugye ez jelentősen függ az adott helytől.
- A hozzászóláshoz be kell jelentkezni
Én is zfs send-et tervezek csak egy lokális diszkre, mert akkor nem kell átutazni az egésznek a hálózaton kétszer.
- A hozzászóláshoz be kell jelentkezni
/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 hozzászóláshoz be kell jelentkezni
Pontosan mit akarsz flamelni? Érted mi történt vagy csak bele akarsz rúgni valamibe?
Ahogy látható az úr egy 2017-ben kiadott zfs verziót használ. Mi a probléma?
- A hozzászóláshoz be kell jelentkezni
Az nekem hiányosság, hogy nem lehet raidZ1/2 -t lemezzel bőviteni. Olvastam, hogy majd lesz.
Ezt a parncsot így már nem lehet kiadni véletlenül ? Mért az értelmeten öszeálítások versenyén ez ott lenne a dobogón.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Tudnál mondani egy ilyen production cuccot amire hivatkozol és mondjuk hasonlít valamilyen szinten a ZFS-re
- A hozzászóláshoz be kell jelentkezni
Ezek belsős cuccok a cégben. De semmi akadálya nem lenne, hogy az ingyenes cuccok is tudják ezt, csak mégse tudják.
- A hozzászóláshoz be kell jelentkezni
Összefoglalom, nem mondtál semmit és nem ismered a ZFS-t, de azért csak megszakértetted (ie.: zpool add -n). Egyébként nem kellene összekeverni ócskavas proprietary in-house tooling-ot egy technológia körül egy technológiai megvalósítással
- A hozzászóláshoz be kell jelentkezni
zpool add -n: ez jó, nem ismertem, már csak defaulttá kellene tenni.
ócskavas proprietary in-house tooling: hahaha
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
hat valoban nem, de ahogy olvasom a 2021-ben sem megoldott hogy egy disket eltavolitsunk belole. dejo is az amikor egy hasonlo dolgot egy 200T-as poolon csinal valaki! :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
É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
- A hozzászóláshoz be kell jelentkezni
Willy mondjuk írta, hogy már már nem lehet megcsinálni, amit kérdező elrontott véletlenül:
ezt a malőrt innentől majd csak -f megadásával lehet elkövetni.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Igen, egy 4 évvel ezelőtti verziót használ a kérdésfeltevő.
- A hozzászóláshoz be kell jelentkezni
Vagyis négy eve még szar volt, de mostmár tutijó minden.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Oke, ez már azóta avitva van - vágjuk.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
Annyira, hogy eppen most tortent egy ilyen..
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
Ezért érdemes frissiteni a szoftvereket.
- A hozzászóláshoz be kell jelentkezni
..és produktiv kornyezetbe csak kiprobalt, megbizhato rendszert hasznalni...
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
...amig nem talalnak abban is egy ugyanilyen banalis "feature"-t, amit aztan majd egy zfs 3.0, es tovabbi, toretlenul lelkes rajongoi kommentek fognak kovetni... :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
És hiába javitják majd ki a hibákat, lesznek akik töretlenül hajtogatják majd a 14.0 -nál is :
Jó de mit adtak nekünk a rómaiak ?
- A hozzászóláshoz be kell jelentkezni
...ahelyett, hogy már kezdettől fogva hasznaltuk volna azt, amit eleve arra terveztek, ugye kedves, kiserletezo kedvu kollegaim?!. :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
Nagy bajban lennél, ha nem lennének kisérletező kedvű kollégáid... ;)
- A hozzászóláshoz be kell jelentkezni
Most nem tudnék kinek valaszloni, de ez azért mégse lenne akkor nagy baj, igaz?!. :) annak viszont tenyleg nagy baj, aki jol megszivta vele...
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
..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
- A hozzászóláshoz be kell jelentkezni
Inkabb a szeles korben hasznalt, ipari standard megoldasoknal. :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
Ja, hogy ez a zfs-rajongoi fanclub... Ok :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Miutan leirtam, hogy senki sem 100%-ban tokeletes, en sem. En gratulalok, te legalabb nagyon szakmai vagy (vagy inkabb fanboy?) :)
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
Észre kellene venni, hogy nem rád vagyok mérges, hanem arra amit képviselsz fent. Ha ezen megsértődsz, hát ezen nem tudok segíteni. De légyszi gondolkozz, számodra szimpatikus lenne olyan világban dolgozni amit ez generál.
- A hozzászóláshoz be kell jelentkezni
É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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ahhh, ez a maganugyed (ezek szerint ez neked nem ment at)..
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 ?
- A hozzászóláshoz be kell jelentkezni
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.- A hozzászóláshoz be kell jelentkezni
Ó, ez nagyon várva várt. :-)
- A hozzászóláshoz be kell jelentkezni
Írtam mailt, ha tudok segíteni, keress meg.
- A hozzászóláshoz be kell jelentkezni