- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Közben válasz magamnak. A diasorból kiderül, hogy a packet = package.
Elolvastam, nyújtóztam, ásítottam. Alvás.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Én azt nem tudom továbbra sem ép ésszel felfogni, hogy mi fog történni, ha itt tényleg megtörténik az a nagymértékű haladás, amit ígérnek.
Egyrészt ki a frászt fogja érdekelni, de ez a kisebbik gondom :), a nagyobbik az, hogy mi lesz, ha ezek eljutnak a ZFS-sel a 152-es verzióig, egy hordányi új fícsörrel, majd bang, öt év múlva megjelenik az első Solaris forráskód az Oracle-től, ahol a 462-es verziónál tartanak hordányi^2 fícsörrel.
Nem lesz megoldhatatlan kihívás ezt a két ágat úgy összefésülni, hogy közben kompatibilitást ígérnek a Solaris 11-gyel, aminek a forrását nem látják, ergo nehezen fogják implementálni a benne található hordányi^2 funkciót, mikor pedig végre hozzájutnak, ők már teljesen máshol tartanak, az Oracle viszont soha nem fogja visszaportolni az ő módosításaikat?
suckIT szopás minden nap! kqueue Javához!
- A hozzászóláshoz be kell jelentkezni
De. Most az új Solaris és Sun Cluster megjelenéssel is volt egy csomó dolog, ami nem volt eddig az OpenSolaris-ban, csak nemrég tolták bele azokat is, pedig biztos jó ideje készülnek. A ZFS meg teljesen jó példa, logbias \o/, ZIL synchronicity, RMW, zpool recovery \o/, mik is voltak mostanában? Fogalmuk se lesz róla, mi történik. Ilyet, hogy SPARC fast reboot (mondjuk ez se rossz) mondjuk el tudom képzelni, hogy gyorsan átraknak, ahogy megjelenik, elnézve a módosítások gyakoriságát azokon a kódokon :)
- A hozzászóláshoz be kell jelentkezni
Halál ez, akárhogy is próbálom megfejteni.
A logbiasról pedig csak az jut eszembe, hogy szánalom, ilyen háttérrel, és hype-pal már bőven per processz szabályozható io prioritásoknál, garanciáknál, és hasonlóknál kellene tartaniuk.
A ZFS-ről egyre csak arra gondolok, hogy amekkora észnek kiáltották ki magukat a megalkotói, akkora hibákat követtek el a tervezéskor...
suckIT szopás minden nap! kqueue Javához!
- A hozzászóláshoz be kell jelentkezni
"akkora hibákat követtek el a tervezéskor..."
Pl. milyen hibákat?
- A hozzászóláshoz be kell jelentkezni
Majd ha egyszer nagyon ráérek, összegyűjtöm azokat a postokat, leírásokat, bejelentéseket, amelyekből ez az érzésem kialakult az elmúlt öt évben.
suckIT szopás minden nap! kqueue Javához!
- A hozzászóláshoz be kell jelentkezni
Nekem nem leírások vannak, hanem atom nagy szopások, éjszakázások meg borulások :)
- A hozzászóláshoz be kell jelentkezni
akkor minek használod?
Van a mazochizmusnak kevésbé kemény formája is... :)
- A hozzászóláshoz be kell jelentkezni
van olyan, hogy not my choice, meg hogy ezzel együtt is ez a legjobb, meg hogy sok egyéb dolog miatt még mindig a Solaris Cluster a legjobb választás (ezt ugye nem kell sorolnom), és akkor már zfs.
- A hozzászóláshoz be kell jelentkezni
hát nemtom.... van pár Solaris clusterem, de egyik alá sem került zfs... (bár valószínűleg kényelmesebb lenne, mint metasetekkel krampácsolni, de azok legalább nem borulnak...)
- A hozzászóláshoz be kell jelentkezni
ok, de ne a freebsd listából ollózd ki őket ...
szerk: tényleg kiváncsi vagyok, mert zfs-t kb. 1%-ba használok a többi fs-hez képest, azzal az 1%-al meg nem nagyon volt semmi nyűgöm...
- A hozzászóláshoz be kell jelentkezni
én még mindig ott tartok, hogy ha van egy cache-centrikus enterprise storage-od, akkor még mindig a legjobban úgy jársz, ha az adatbázis lognak csinálsz külön zpool-t, ami _alig nagyobb_, mint a logjaid. (még jobb lenne ugye a zilt is kikapcsolni, de ugye global setting és a datadirekhez meg kell, meg hát ellenjavallt.) párszor már "rengeteget" javult a dolog és nem kétséges, hogy egy kisebb méretű storage-on gyakorlatilag jobban jársz, ha rátolod az egészet egy nagy zpool-ra, mint ha nekiállsz "hagyományos" fájlrendszerekre szabdalni a dolgot. de egy nagyobb storage-nál marhára nem mindegy, hogy a cache benyeli a logot és nem keletkezik háttértranzakció, vagy a ZFS teleszemeteli az egész zpool-t akkor is, ha ugyanazokat a 4 gigás fájlokat írod (COW...) és a storage cache átalakul egy bufferré a gép és a lemezek között, nem mellékesen teleszemetelve azt is. végül is nem akkora gáz a külön zpool, de messze nem "as advertised", meg be kell delegálni a datasetet (pathname érdekességek), clusternél betenni a hasp-be, ha már hasp akkor RG switchnél 2 zpool-ért imádkozni, hogy simán menjen, mert ha nem, akkor az egész géped döglik, jó esetben csak a zfs, df -h, stb parancsok fognak befagyni és üzemelhetsz tovább, rossz esetben panic, ha volt egy jó nagy zpool-od mountolva a gépen, akkor lehet reménykedni, hogy a cluster resource-okban elég legyen a timeout, mert egy 2 terás dataset recovery-je bizony 20 perc (szerintem az átlagosnál gyorsabb diszkekről), nem mintha más fájlrendszerrel gyorsabb lenne, de ebben az esetben nem jó, hogy nem kiszámítható, és hogy a zfs, df -h csomó minden behal, amíg tart (mintha olvastam volna most valamit zpool-onként külön processzről), és hogy a cluster doksikban/scriptekben szó nincs ezekről az esetekről, pedig léteznek. workaround: clrg offline, tartalék gépre átprezentálni a LUN-t, ott megvárni, amíg befejeződik a zpool import (tart, ameddig tart), zpool export, utána a clusteren mehet a clrg online :)
- A hozzászóláshoz be kell jelentkezni
szvsz rég rossz, ha egy fájlrendszert így kell tutujgatni. a post-odból kb. semmit nem értettem, de szerintem egy használható rendszernek nem így kéne kinéznie. lehet, csak nekem nagyok az igényeim.
szerintem.
- A hozzászóláshoz be kell jelentkezni
igen, de egyben azt most rögtön leszögezem, hogy linux,ext3,xfs,btrfs,drbd, meg mit tudom én mik fognak mindjárt elhangzani, _más kategória, más problémák_.
- A hozzászóláshoz be kell jelentkezni
azt áruld már el, hogy a fenti setupban mi az ami miatt zfs-re esett a választás?
- A hozzászóláshoz be kell jelentkezni
így is ez a legjobb, most még ezer dolgot tudnék említeni, hogy miért szar, de pro/con egymás mellé írva is messze ez a nyerő.
- A hozzászóláshoz be kell jelentkezni
Ugyan már, a RHEL cluster mindenben tökéletesebb Ext3-mal, pl. simán mountolódik mindkét node-on. :)))
--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.
- A hozzászóláshoz be kell jelentkezni
"ha van egy cache-centrikus enterprise storage-od, akkor még mindig a legjobban úgy jársz"
....ha dobod a francba a zfst. Vagy ha már mégis, akkor csinálsz egy 20 diszkes raid 10-et, és kikapcsolod a zil-t.
Oracle alá amúgy is durván dupla bufferelés egy zfs (na persze, ha elég ram van a vasban....).
Nem értem mi a francnak szopatják emberek magukat cluster+zfs kombóval. gondolom az olyan feature-ök miatt, ami ufs-ben nincs meg, viszont clustert általában olyankor használ az ember, ha a nagyon fontos a rendelkezésre állás...
"workaround: "
Tök jó, csak éppen, ha nem rg switch van, hanem failover (tehát amikor leginkább működni kéne), akkor nem használható.
Félre ne érts, szeretem a zfs-t, csak egész egyszerűen van olyan alkalmazási terület, amire totál alkalmatlan.
- A hozzászóláshoz be kell jelentkezni
ARC szerintem nem probléma, ami RAM tegnap soknak számított, az ma kevés, és ha ismered a működését, akkor még nyersz is rajta, mert úgy konfigurálod a LUN-hoz a cache-t (ami ált. szűkebb, mint a hostokban a RAM)
rendelkezésre állás egy dolog, másik hogy ezt mennyi energiával éred el, mert mondjuk biciklivel is el lehet hordani egy raktárat meg kamionnal, sőt a bicikli még nagyobb rendelkezésre állású is lehet, mert ha egyet elütnek, a többi doboz még odaér, csak a gyakorlatban alkalmazhatatlan, ha viszont vannak rendes kamionjaid, akkor lehet, hogy felszabadul egy csomó erőforrás és megnyílnak a lehetőségek.
1 db solaris clusterre baromi egyszerű ezer féle szolgáltatást rátenni minimál munkával. rendelkezésre állás vs munka arány kitűnő. ha akarsz, lehet csak a rendelkezésre állás is szempont, akkor nem úgy csinálod. de amúgy scalable cuccok is vannak nem csak failover.
amúgy meg ufs mennyi idő alatt fsck-zik meg 2 terát, mondjuk 60K-s fileokkal tele, vagy épp ext3? HASP esetén ez ugyanúgy játszik, global file system igaz nem tud lenni a zfs, de úgyse raknál rá nagy I/O-t..
- A hozzászóláshoz be kell jelentkezni
"amúgy meg ufs mennyi idő alatt fsck-zik meg 2 terát, mondjuk 60K-s fileokkal tele, vagy épp ext3? "
Ha ez akkora gáz, miért nem csinálsz 10db 200G-s file rendszert? Kizárt, hogy minden egyes alkalomkor recovery-zni kéne mindet, főleg, ha logging.
Egyébként meg vxfs....
- A hozzászóláshoz be kell jelentkezni
Nem mondtam, hogy akkora gáz, csak megjegyeztem, hogy a többi cucc sem jobb ebben az esetben semmivel (sőt).
- A hozzászóláshoz be kell jelentkezni
ezt elmondták a bejelentésben.
elméletileg az új fícsörökkel az Oracle mögött loholnak, és remélik hamarosan hozzájutnak a kódhoz.
Egyébként amilyen ütemben lépnek ki az Oracle-ből a régi a Solaris fejlesztők....
1-2 éven belül az indiában ücsörgő új Oracle-Solaris fejlesztő már az Illumos forráskódbol másolja át az új fícsöröket az Oracle-Solaris forrásába....
- A hozzászóláshoz be kell jelentkezni
Igen, szerintem is sorban fognak állni a nagyvállalatok, hogy supportálhassák a saját szoftverüket/hardverüket illumoson/ra, a mostani Solaris userek pedig licenceket akarnak majd venni, hogy az orákulumtól kilépett, túlfizetett blogkirálynőket továbbra is tudják foglalkoztatni.
Sokan bármit megtesznek, csak hogy Bonwick le tudja cserélni az öregecskedő Lexust a ZFS ROX rendszámtábla alatt.
suckIT szopás minden nap! kqueue Javához!
- A hozzászóláshoz be kell jelentkezni
Reális lehetöség.
:-)
- A hozzászóláshoz be kell jelentkezni
ezt majd meglatjuk..
ahogy Alasdair is mondta a bejelentesbe: "az oracle hazudott mar nekunk, 50% hogy megint fog" vagy hasonlo, szal eloszor varjuk meg kifogja e adni a sourceot az oracle
- A hozzászóláshoz be kell jelentkezni
es mikor jon el az openindiana desktop eve? :)
- A hozzászóláshoz be kell jelentkezni
Miért nem érdemes erőltetni a Solaris közösségi fejlesztését?
Tegyük fel, hogy hívei vagyunk a sokféleségnek. Szerintem jelenleg elég sok közösségi fejlesztésű os van: Linuxok, BSD-k, egyebek. A közösségi fejlesztés híveinek van elég terep, ahol kiélhetik az alkotó vágyaikat. A nyílt Solaris ezek mellett az egymástól alig különböző rendszerek mellett csak egy sokadik volna, a sokféleséget érzékelhetően már nem növelné. Ugyanakkor, a másik oldalról (a központosított irányítás alatt fejlesztett os-ek köréből) érezhetően hiányozna.
Szerintem ma már jól láthatók a nyílt fejlesztés korlátai. Nem azt mondom, hogy például a Linux ne volna használható. Nagyon is használható, magam is Linuxon (és Solarison) futó programok írásából élek. De valahogy a Linux mindig félkész állapotban van. Például az Ubuntu felerészben systemv init scriptekkel, felerészben upstarttal működik és hasonlók.
Az Oracle a Solarist az adatbáziskezelő fő platformjává akarja tenni. Érthető, ha egyszerűen nem akar bajlódni a fejlesztői közösséggel, a hektikusan változó fejlesztési irányokkal. Ezért lemondanak a közösségtől kapható rengeteg "hasznos kontribúcióról", nem érdekli őket az ezerféle wifi driver, mobil internet, gnome applet, hanem a szerverre koncentrálnak, és saját kézben tartják a fejlesztést.
De miért is kéne mindent ugyanarra a kaptafára húzni?
--
CCC3
- A hozzászóláshoz be kell jelentkezni