Frissült az OpenIndiana (oi_151a5)

Solaris, OpenSolaris, Illumos

A napokban friss pre-stable kiadás (oi_151a5, vagy más néven oi_151a_prestable5) érkezett az OpenIndiana-ból. Ez az ötödik azóta, hogy a kezdeti Illumos-alapú oi_151a megjelent tavaly szeptemberben. Az oi_151a_prestable5 egy bug és security fix kiadás. A kiadás ISO(-k) formájában érhető el. Ez az OpenIndiana első olyan kiadása, amelyben megjelenik az Illumos ZFS feature flags koncepció.

A változásokról részletesen a kiadási megjegyzésekben. Az ISO-k elérhetők itt.

( balintdavid | 2012. 07. 11., sze – 19:34 )

Pár éve kipróbáltam, bár akkor még lehet OpenSolarisnak hívták épp. Remélem a FreeBSD/PC-BSD community majd egyszer lekoppintja a Time Slider ZFS snapshot vizualizációs cuccost

( joco01 v | 2012. 07. 11., sze – 20:16 )

Elolvastam a feature flags doksit. Csak egy idézet: "What happens when Delphix uses the 59th bit in the block pointer as a flag and Joyent uses bits 56-63 to store an enum value?" És ír még más cégeket is, akik párhuzamosan fejlesztenek... Ennek a ZFS-nek lőttek :)

--
joco voltam szevasz

Ahogy látom, te most nagyon keménynek és zseniálisnak érzed magad, de ettől még válaszolok érdemben.

Az idézetem innen jött: "Feature flags does not help merge code for two conflicting features". Amúgy én értem, hogy próbálják egységesen kezelni a verziózást, de ha már ennyien fejlesztik eltérő irányokban, igenis lesznek inkompatibilis feature-ök és implementációk. Mostantól ezt majd biztonságosan detektálni lehet a feature flag-ekkel, de ne mondd már, hogy ebből sose lesz gondja senkinek. Pl. akkor számít a flag, ha rendszerek között akarsz egy diszket hordozni, de ha van egy hiányzó feature a másik rendszerben, akkor szép hibaüzeneted lesz, használható diszked nem. Minimum vitás kérdés, hogy egy fájlrendszer formátumának divergálása jót tesz-e.

--
joco voltam szevasz

Ha bekapcsolsz egy feature-t akkor valószínűleg azért teszed, hogy használd is. Ha egy másik rendszerre akarod a diskedet átvinni akkor gondolom ott is szeretnéd használni a feature-t. A megoldás a zpool upgrade. Ha meg nem szeretnéd használni akkor marad a readonly (egyelőre). Csak egy kis odafigyelés.

Látom az értő olvasás nem megy...

Egyrészt, a feature-t te csak enabled állapotba tudod tenni a doksi szerint, másrészt, külön kezelendő ettől, hogy ilyenkor még az adott feature ismerete nélkül ro-ban használni, vagy azt sem...

A probléma, mint arra utalnak, és amit idéztél, az az, hogy mi van, ha valaki az 55-63-as bitig lefoglalja magának a biteket, és közben meg másvalaki bebillenti az 59-es bitet, minden szó nélkül.

Ezt nem oldja meg ez a koncepció, de azt írják, hogy mielőtt elkezdenél használni egy bitet, fogod magad, és a tervedet megosztod a devel listán, jóváhagyják, hogy megkapd az xy bitet, és utána a tiéd, és használhatod. Te meg, ha a "mainstreammel" kompatibilis akarsz maradni, akkor nem csinálsz n+1. külön zfs verziót, mert az nem jó, hanem együtt működsz a commite-vel, különben a kutya nem fog komolyan venni, de ez meg már a social enginiering oldala a dolognak.

( subchee | 2012. 07. 12., cs – 11:51 )

Az elég vicces, hogy ftp-n keresztül ezen a címen csak rhel/centos/scientific cuccokat lehet letölteni: ftp://dlc.openindiana.org/ és az OpenIndiana iso-kat meg nem.