OpenIndiana bejelentés

 ( trey | 2010. szeptember 14., kedd - 20:54 )

Idézet:
19:50 - a bejelentés még nem kezdődött el
19:51 - elkezdődött a bejelentés
19:51 - Mi az openindiana - az Opensolaris folytatása ... de ezt a közösség fogja építeni
19:52 - célja, hogy packet (? - a szerk.) és bináris kompatibilis legyen a Solaris 11-gyel, a Solaris 11 express-szel ...
19:52 - az illumos közösség része
19:51 - jelenleg 20 core fejlesztő
19:53 - a de-facto opensolaris disztribúció kíván lenni
19:53 - bináris tartalmat is fog kínálni
19:53 - "stable" ág hibajavításokkal
19:54 - rendszeres fejlesztői build-eket kínál majd
19:54 - 100% ingyenes és 100% nyílt forrású ... noha 100%-ban nehéz nyílt forrásúnak lennie a driver-ek miatt
19:55 az első fejlesztői build, az ou_147 elérhető most!
[...]

[ Bejelentés transcript | a bejelentés diái ]

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

É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!

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 :)

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!

"akkora hibákat követtek el a tervezéskor..."

Pl. milyen hibákat?

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!

Nekem nem leírások vannak, hanem atom nagy szopások, éjszakázások meg borulások :)

akkor minek használod?
Van a mazochizmusnak kevésbé kemény formája is... :)

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.

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...)

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...

é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 :)

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.

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_.

azt áruld már el, hogy a fenti setupban mi az ami miatt zfs-re esett a választás?

í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ő.

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.

"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.

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..

"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....

Nem mondtam, hogy akkora gáz, csak megjegyeztem, hogy a többi cucc sem jobb ebben az esetben semmivel (sőt).

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....

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!

Reális lehetöség.
:-)

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

es mikor jon el az openindiana desktop eve? :)

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