Volt egy időszak, amikor viszonylag kiszámíthatóan működött a ZFS a FreeBSD-ben, aztán ez hirtelen megváltozott, és előjöttek a korai ZFS-port panic-jai a kmem_map too small képében.

A kernel countereket figyelve úgy tűnhet, hogy a ZFS felzabálja az összes kernelmemóriát, ez főleg 32 bites rendszereken lehet érzékeny pont.

A hibát úgy tűnik, hogy az UMA bekapcsolása okozza, amin pjd és kmacy össze is különböztek. Talán jó alkalom lesz ez arra, hogy végre rendbetegyék a ZFS memóriafoglalása körüli legidegesítőbb problémát.

Threads were invented as a very bad workaround for slow context
switching on ancient hardware using primitive OS versions.
The people who invented them said they were bad.
Any teacher or programmer who says otherwise is ignorant.
There's a paper from Berkeley showing how a threaded program can
never be fully debugged and should be presumed to be broken,
probably fatally broken.

geoff steckel

Mit tegyenek azok, akik iPadra vágynak, de csak egy iPhone-juk van, pénzük meg nincs még egyszer megvenni ugyanazt, csak nagyobb kijelzővel?

A megoldás egyszerű, csak egy megfelelelő nagyító kell hozzá:

Annyira egyszerű, hogy még a nagyi is tudja használni:

Sőt, anyunak is odaadhatjuk, az iphone-ot a hímzésére helyezve, és a nyakába akasztva egy világítós nagyítót tökéletes ipad-élményben lehet része!

Szombaton arra a kínzó, gyötrelmes kérdésre ébredtem, hogy mit választanék, ha lenne mondjuk egy PiB-nyi e-mailem, de mégis annyira elmaradott lennék, hogy azokat nem valami speciális adattárban, hanem hagyományos fájlrendszerben tartom. A fájlokat tömöríteném, egyesével, vagy a fájlrendszert (és a fájlrendszer alatt itt most a ZFS-t értem, azon most ne akadjunk ki, hogy valószínűtlen, hogy bárki, aki egy PiB-nyi levelet tárol, ZFS-t használjon)?

Mindkettőnek megvannak az előnyei. Ha a fájlokat külön tárolom, a gyorsan pörgő leveleket tömörítetlenül hagyhatom, míg a pár naposakat valami egyszerű, gyors algoritmussal, a több hónaposakat pedig valami kemény, Amperzabálóval nyomorgathatom.
A fájlrendszer előnyét pedig azt hiszem mondani sem kell: bekapcsolom, és elfelejtem, pontosabban gúvadó szemekkel skubizom a terhelési görbéket, nehogy hamarabb fogyjon el a CPU, mint a rendelkezésre álló tárhely.

A probléma tehát, hogy ha a leveleimet mondjuk Dovecottal, maildirben tárolom, amely képes felismerni, hogy azok tömörítettek (gzip, bzip2), érdemes inkább ezt használni, vagy célszerűbb inkább bekapcsolni a zfs-ben a tömörítést?

A teszt kedvéért fogtam pár üzleti levelet (azaz bőven vannak bennük excelek, meg wordök), és összenyomtam őket így is, meg úgy is. 24 ezer e-mailről van szó, összesen 1 GiB méretben. Az adatok memóriadiszken voltak mindvégig.

A kernel nevű számok a ZFS-sel tömörített, míg a user a gzippel tömörített esetet jelentik. lzjb csak a ZFS-ben van, a bzip2 pedig csak userspace-ben.

Mit lehet megállapítani? Először is azt, hogy az lzjb gyors, cserébe nem tömörít valami jól, az eredeti méret csupán 83%-ára tudta összepréselni az e-mailjeimet.
Hozzá képest a gzip, még a leggyorsabb módban (-1) is egy vánszorgó csiga, mert hiába nyomja össze a leveleket majdnem a felére (azaz kb. 1,8-szor annyi helyet tudunk használni, mint amekkora merevlemezt veszünk), ezt több, mint kétszer olyan lassan éri el, mint az lzjb.

Az első érdekesség itt látszik: a ZFS gzip -1-e és a fájlok egyesével történő becsomagolása közt két százalékpontnyi különbség van. Ennek egy lehetséges oka az, hogy a gzip program egész leveleket kap, míg a ZFS a 128 KiB-os rekordjait tömöríti.
A másik érdekesség a tömörítés ideje, amelyben a ZFS és a userspace-ben futó gzip között több, mint kétszeres eltérés van, a ZFS javára. Ennek feltételezett oka az, hogy a userspace-ben futó tömörítést szekvenciálisan végeztem, azaz egy gzip program ment végig mind a 24 ezer fájlon, sorban. A kernelben futó ZFS viszont nem akkor tömörít, amikor megkapja az adatokat, hanem ráér a munkát elvégezni később, a diszkhez "közelebb", hiszen szuboptimális lenne egy gyorsan változó fájl blokkjait egymilliószor betömöríteni, mikor diszkre csak egyszer kerül ki. Ez önmagában még nem magyarázza a dolgot, hiszen ha a kernelben futó gzip -1 implementáció megegyezik a userspace-ben futóval, annak nem szabadna kétszer olyan gyorsnak lennie.
A drasztikus eltérés okaként én így a ZFS-ben megvalósított párhuzamosítást képzelném, hiszen össze tud gyűlni a pufferekben sok adat, és amikor eljön a tömörítés ideje, az ott lévő blokkok párhuzamosan tömöríthetők (a gépben 8 CPU mag volt). Read the source Luke, de ehhez most lusta vagyok.
Az elképzelést mindenesetre alátámasztani látszik a kitömörítés, hiszen ott a user és kernel megvalósítás közt alig van különbség. Ennek oka a fenti elmélet szerint pedig az, hogy olvasáskor nem lehet párhuzamosítani, hiszen a cp egy szálon tölti be az adatot (nos, a prefetch ezen azért változtathatna, de ezek elég kis fájlok ehhez).

Az igazán durva értékek a gzip -9 felé haladva kezdenek kialakulni, 122 másodpercet várni 1 GiB betömörítésére azért kemény dolog. A ZFS-es 30 másodperc itt ennek fényében világbajnoknak tűnhet, de vegyük hozzá, hogy ezalatt a 30 másodperc alatt a gép annyira beáll, hogy az ssh konzolon sem lehet gépelni...

A bzip2-re túl sok szót nem is pazarolnék, a bzip2 -1-et hívhatnánk akár gzip -10-nek, a -9-et pedig -19-nek, olyan szépen folytatja a gzip által megkezdett időket (nos, kivéve a kitömörítést, abban ugyanis egy bazi nagy ugrás van).

Összességében az látszik, hogy a gzip -1-hez képest 5%-ot nyerhetünk a tömörítésben, de cserébe négyszer annyit kell az eredményre várni, ami nagyon ritkán érheti meg.

A fentiek alapján azt gondolom tehát, hogy ha 1 PiB-nyi levelem lenne, és ezekben (csak a saját levelezésemből kiindulva) be tudnék azonosítani három jelentős réteget, azaz:

1. a nagyon gyorsan pörgő levelek
2. a gyakran használt levelek
3. a szinte sosem használt levelek

akkor érdemes lenne megfontolni ezek sávos tömörítését. Az elsőét lzjb-vel (vagy semmivel, bár az lzjb-be érdemes beleszámolni, hogy a diszkekre eső IOPS-igényt hatékonyan cserélhetjük be vele CPU idő-igényre), a másodikét gzip -1-gyel, a harmadikét pedig gzip -9-cel.
A ZFS és a userspace tömörítés közti konstans 2-3%-nyi különbség miatt pedig ekkora méretekben már megérné a userspace tömörítést választani, amellyel ráadásul hatékonyabban is lehet szabályozni annak erősségét.

TAC-os embertől jött, e-mail aláírásban:

       .            .          ****** *****
       |            |          Customer Support Engineer
      |||          |||         East Coast TAC
    .|||||.      .|||||.       Research Triangle Park, NC
 .:|||||||||:..:|||||||||:.    Email:  ******@cisco.com
  C i s c o  S y s t e m s     Phone:  (919) ***-*****
  
  routers, switches, stock, whatever ..... just buy Cisco

A holokausztot tagadni nem kell félnetek jó lesz ha mindenki egyetért én nem ellenzem.

Az MSZMP-n ne múljon, csak benyomták a holokauszt-tagadás büntetését célzó törvénymódosítást, az indexes "holokamu" cikk alapján

„aki nagy nyilvánosság előtt a holokauszt áldozatának méltóságát azáltal sérti, hogy a holokauszt tényét tagadja, kétségbe vonja vagy jelentéktelen színben tünteti fel, bűntettet követ el, és három évig terjedő szabadságvesztéssel büntetendő”

Wikipédiázzunk. Szerintük a holokauszt állatáldozat égetés általi (vallásos) felajánlása, amely az ősi görög holocaustos szóból ered (hallod Toula Portokalos? Apád megmondta!). Az eligazító oldalon többek között szó esik még "A Holokausztról" (mint történelmi esemény), a képregényes Holocaustról is (itt balra), meg egy ilyen nevű TV-sorozatról, és egy zenekarról is.

Valószínűleg "A Holokausztról" van itt szó, bár könnyen el tudom képzelni, hogy a Holocaust nevű heavy metal bandának is áldozatul eshet valaki. Jelentéktelen színben feltűntetni meg sem próbálom őket, hiszen sosem hallottam őket játszani, bár ha a Dohány utca elején lévő boltban lehetne kapni a kazettájukat, biztosan megvenném, és meghallgatnám. Letölteni nem merem, mert lassan azért is megb.szhatnak.

Szóval egyelőre induljunk ki abból a feltételezésből, hogy az indexes cikk "A Holokauszt" nevű eseményről szól.
Az erről szóló cikk szerint:

[...]the term generally used to describe the genocide of approximately six million European Jews during World War II[...]

Some scholars maintain that the definition of the Holocaust should also include the Nazis' systematic murder of millions of people in other groups, including ethnic Poles, Romani, Soviet civilians, Soviet prisoners of war, people with disabilities, homosexuals, Jehovah's Witnesses, and other political and religious opponents.^[5] By this definition, the total number of Holocaust victims would be between 11 million and 17 million people.^[6]

Jó bevezető, ha most hallanám életemben először ezt a szót kicsit elbizonytalanodnék. Mi a fenét is jelent akkor "A Holokauszt"? Égetett állatáldozatot, 6 millió zsidó, vagy 11-17 millió egyéb, ebben az időszakban a nácik által megölt embert, tv-sorozatot, vagy heavy metal bandát?
Mit tehet az, aki ezirányú műveltségre vágyik? Megnézheti például a témában készült több, mint kétszázötven filmet (úgy tűnik mind nácis gyilkolós), esetleg a különböző háborúk, katasztrófák halálos áldozatainak számát (A Holokauszttal kapcsolatban is mindig ez a baj, egyesek jönnek azzal, hogy az áldozatok becsült száma többet esett '45 óta, mint az OTP részvény árfolyama a mélypontig), ahonnan kiderül, hogy a törvénymódosítás által feltételezhetően hivatkozott embertelenkedésekben legkevesebb 5,8, legfeljebb 7 millió zsidó (és még egyszer ennyi nem zsidó) halt meg.

Érdekes egyébként ez az áldozatos oldal, az örmények holokausztjában (lehet ilyet mondani? Még mindig nem teljesen értem a szót ebben a környezetben) legfeljebb 1,5 millióan vesztették életüket, azaz ha statisztikai alapon közelítem meg a dolgot, legalább 60 filmnek kellene szólnia az örmény nép írtásáról, és ha visszakanyarodok "A Holokauszthoz", a Wikipedia szerint pont ugyanennyi cigány ember távozott a mennyek országába ciklon-B által, ennek ellenére Schindler listáján elég kevés volt a Kolompár.

Azt hiszem "A Holokauszttal" két kisebb probléma van: túl jó a marketingje, és túlságosan egyoldalú.

És egy óriási: megtörtént. Ha nem így lett volna, valószínűleg az átlagmagyar tizenpáréves koráig azt sem tudná, hogy eszik-e vagy isszák a zsidót, ennek megfelelően antiszemitává is csak akkor ezután tudna válni.

Erről a commitról jutott eszembe, hogy milyen kusza is az élet.

A lófarkas főmufti CDDL-lel osztja meg a solaris.torrentet, nehogy a zfs.tar az /usr/src/linux-ba kerüljön. Aztán az ördögös lengyel csak betölti ezt a bsd-s tarral, majd Molnár Marcel hackel rajta kicsit, és végül az otthonaként a SPARC-ot tekintő Solaris groundbreaking new feature-e egy teljesen másik OS-ben kel életre a nagy ellenség, az Intel Itanium tranzisztorain.

Zsír.

Az előző post feketeöves beállításairól jut eszembe, hogy használjunk Javát 3.6-os Firefox-szal:

Úgy kezdődik, hogy:

sudo apt-get remove --purge icedtea6-plugin
sudo apt-get install sun-java6-plugin

Még szerencse, hogy az Ubuntu az Apple-lel szemben gyorsan fixálja a Java bugokat, oh wait, miben is?

Korábban már volt itt szó a HP MDS600 nevű ketyeréjéről, amely ismereteim szerint a jelenlegi diszksűrűség-rekorder.

Jócskán lemaradva a cikktől ;) bra csak most kapott észbe, és tolt ide két képet azzal a szöveggel, hogy: "Lehet, hogy hamarosan irigykedni fogsz. :)"

A lényeg ugyan nem látszik, de lehet. Ha valami jó képet kapnék, lecserélném az idejét múlt sunos fejlécet is, csak a dobozt mozgató emberek intim kapcsolata azon is tetten érhető legyen. =)

CPU:  0.4% user, 23.2% nice, 53.2% system, 23.2% interrupt,  0.0% idle

Ebből kiderülhet, hogy mi történik: hálózatról másolok kb. 200 rsync-kel.

Simpson, írd fel ezerszer a táblára a tanulságot!

... mindig arany.

John Baldwintól leltem rá nemrég erre a kis aranyosra, amely azt taglalja, hogy mégis mennyire kellene állítani a kern.maxswzone értékét, ha esetleg belehalna a gép abba, hogy ez kevés:

What I typically do for this panic is get the 'swapinfo' from the crash dump, 
and use (number of blocks in use) * (total swap blocks) / (maxswzone) to 
compute a new value for kern.maxswzone.

Admin friendly nagyon. Erről eszembe jutott az egyik első FreeBSD-s kalandom, próbaképpen párezer processzt akartam rajta indítani, mire az aieee, killing interrupt handler, ja nem, az a Linux, szóval pánikolt.

Azóta valahogy azt érzem folyamatosan, hogy a FreeBSD-ben még mindig túl sok a "feketeöves", mágikus változó, amelyek céljáról, beállítási tippjeiről szinte senki sem tud.

Beteg-e vagyok?, kérdezi olvasónk, aki a MikeRoweSoft-hoz hasonló pereket vizionál a kékmetróban, miközben a szerelvényre vár, és az egyik olyan mobilszolgáltató reklámplakátját nézi, amelyik se nem piros, se nem dőlt még össze, ellenben propeller.

"A Sun brand megmarad", ez jól látszik a www.sun.com-on, amelyen csak Oracle logóval lehet találkozni. És itt vannak az új UltraSPARK rendszerek! SPARKz yourz life up!

Package manager error, crash report, hard disk failure...

Cover me, I have to help my mother with the turkey.

Ki kell nyernem kb. 1 TB-nyi logból mindenféle adatot, erre pedig számomra a legkényelmesebb a python. A feladat nagy része regexppel az engem érdeklő sorok, a bennük lévő információ megtalálása, majd ezek kigyűjtése egy dictbe (állapottábla-szerűen), végül pedig az eredmény kiírása (egy sor).

A gép, amin a program fut egy pécé Debiannal, és ennek köszönhetően egy régi Pythonnal (2.4.4).

Kíváncsi voltam, hogy melyik verzióval fut le gyorsabban a program, így egy 1 millió soros inputon kipróbáltam pár verziót, mindegyiket ötször lefuttatva, az öt futásból a legrövidebb időt kiemelve:

Tanulság: a legújabb nem mindig a legjobb. :(

ui: az unladen swallow viszonylagos lassúsága valószínűleg a menetközbeni JIT-nek köszönhető, ami a -j always-szel eltűnik (pontosabban induláskor megtörténik, azaz később nem lassít)

Kenyér és cirkusz kell a népnek, ezt már régóta tudjuk.

Pár hónapja a BKV az, amivel el lehet terelni a figyelmet, amin az egyszerű emberek kiélhetik a naivitásukat, és elhihetik, hogy tényleg van Magyarországon igazságszolgáltatás, amely megbünteti azokat, akik a törvényeket nem tartják be.

A leginkább "legszebb öröm a káröröm" kategóriás hír most a céggel kapcsolatban, hogy Szalainé Szilágyi Eleonóra ellátását (koszt és kvártély) átvállalta a magyar állam, arra hivatkozva, hogy esetleg bizonyítékot semmisítene meg, vagy összebeszélne valamelyik tettestársával.
Az indexen a cikket író fontosnak tartotta megemlíteni, hogy:

Az igazgatónőt egyébként a Gazdagréti lakótelepen lévő lakásából vitték el a rendőrök.

Ez sokaknak szemet szúrt, hiszen szerencsétlen nyomorult átlagpolgár havi 2,5 milliós fizetéssel, és 100 milliónyi végkielégítéssel ritkán vágyik a gazdagréti lakótelepre Komlós Juci és Kulka János szomszédságába, a panelbe, inkább valami jobb fekvésűt választ.

Valószínűtlen (szokás szerint), hogy a kisember megtudja, hogy mi is történt, mennyit (és legfőképpen kik) nyúltak le a BKV-ból a szolgáltatás kárára, de a fentiekből sokak fogják úgy érezni, hogy Nórika csak egy báb, a háttérben ennél nagyobb disznóságok is történtek, amiket sosem fogunk megtudni.

Akárhogy is, én jó vastagon bekenném disznózsírral a képem (az illető hölgy ezt elhagyhatja, neki már így is elég vastag a bőr ott), és a bíróságon azzal védekeznék, hogy az a 100 millió csak cafeteria volt, amelyért BKV bérletet kell majd vásárolnia. Az meg még adómentes. Volt. 2009-ben.

Azért persze bízzunk abban, hogy ha Szalainé, és a többi kretén a Gazdagréten nem is voltak szomszédok, a rács mögött még lehetnek. Én már most felajánlok egy éves BKV-bérlet gyűjteményt, amivel majd kártyázhatnak bent.

Szokás szerint semmi komoly, csak egy könnyű nyár végi (elaludtam kicsit) IMAP szerver benchmark.

A használt gép nem túl durva, valami egy procis amd64 dzsunka, mögötte RAID0-ba kapcsolt SATA diszkekkel, FreeBSD 8-cal, és ZFS-sel. Log diszk külön.

A teszter a dovecot imaptest, amellyel csak append és mixed workloadot próbáltam. A mixed workload nagyságrendileg ezt jelenti:

Totals:
Logi List Stat Sele Fetc Fet2 Stor Dele Expu Appe Logo
100%  50%  50% 100% 100% 100%  50% 100% 100% 100% 100%
                          30%                  5%     
4647 2330 2352 4644 4540 6462  518 3676 4540 4644 9294

Íme az eredmények:

A szoft varék kb. a default beállításokkal mentek mindenhol.

Mint azt az SSD-ket részletesen bemutató cikkből tudhatjuk, az írási teljesítmény megtartásához nagyon fontos, hogy a flashekre kerülő adatról tudja a kontroller, hogy érvényesek-e, vagy sem (azaz felszabadíthatók, törölhetők).
Ennek jelzésére születendőben van egy TRIM-ként hivatkozott ATA parancs, amellyel az OS jelezheti, ha felszabadítható blokkok keletkeznek.

A Windows 7-ben már támogatott a technológia, és a Linuxba is kerülnek be ilyen változtatások (pld. ext4, btrfs).

Úgy tűnik, hogy a karácsony a FreeBSD fejlesztőket is pozitívan érintette, mert Alexander Motin az új ATA driverben implementálta a TRIM támogatást (a GEOM BIO_DELETE műveletét feldolgozva). Ez egyelőre csak azt jelenti, hogy az ada(4) driveren keresztül az SSD TRIM és a CompactFlash ERASE támogatott, amit a newfs -E opciójával használhatunk törlésre, és az isaura.avi által elfoglalt hely felszabadítására.

Ahhoz, hogy "menet közben" is működjön, valószínűleg fel kell készíteni a fájlrendszereket is, Alexander (és mások) tapasztalatai alapján azonban lehet, hogy erre még célszerű várni egy kicsit:

I have no idea whether it is normal, but for some reason it takes 200ms to handle any TRIM command on this drive, that was making delete extremely slow.

Wattafuck? Korábban évekig ment a vita a (populárisabb, Free-)BSD-s és a linuxos arcok között, hogy most akkor melyik a jobb, a journaling, vagy a soft updates?

Persze a démonos oldalon túl sok választás nem volt, az ördög ügyvédjének muszáj volt a szoft updatest szeretnie, ellenkező esetben akár azt is mondhatta volna, hogy a Linux a jobb. Márpedig ez megengedhetetlen.

Aztán a vita valahogy alábbhagyott, pedig egy csomó "advanked" fájrendszert (sic, amúgy xfs, reiser"killer"fs) beleszuszakoltak a FreeBSD-be, de csak amolyan tessék-lássék (read only) módon, amikor pedig megérkezett a ZFS is, a vitára úgy tűnt, hogy örökre keresztet vethetünk.

De úgy látszik mégsem, van, akinek nem jó a ZFS (beágyazott rendszereknél mondjuk el is tudom hinni), így az iXsystems, Yahoo!, és Juniper networks kooprodukcióban megérkezni látszik a journaling soft updates a FreeBSD-s UFS-hez.

Jeff Roberson (a szerző), blogjában osztja meg a részleteket, hogyaszongyja:

Soft-updates guarantees that the only filesystem inconsistencies on unclean shutdown are leaked blocks and inodes. To resolve this you can run a background fsck or you can ignore it until you start to run out of space. We also could've written a mark and sweep garbage collector but never did. Ultimately, the bgfsck is too expensive and people did not like the uncertainty of not having run fsck. To resolve these issues, I have added a small journal to softupdates. However, I only have to journal block allocation and free, and inode link count changes since softdep guarantees the rest. My journal records are each only 32bytes which is incredibly compact compared to any other journaling solution. We still get the great concurrency and ability to ignore writes which have been canceled by new operations. But now we have recovery time that is around 2 seconds per megabyte of journal in-use. That's 32,768 blocks allocated, files created, links added, etc. per megabyte of journal.

Na igen, a bgfsck tényleg nem volt egy szerencsés elképzelés, meg aztán TB felett már úgy általában az fsck sem az, milyen dolog már, hogy egy kisebb fájlrendszer fsck-zásához már 64 bites CPU kell, hogy a szükséges RAM-ot meg tudja címezni a rendszer...

Szóval úgy tűnik a ZFS mellett UFS fronton is lesz még némi fejlesztés...

A külső szemlélő számára a Google kétféle (markánsabb) megítélés alá esik. Az egyik (jellemzően nem IT-szakember) szerint ezek ott halálpontosan elterveznek évekre előre mindent, és a zseniális csapat világhódító terve nanométeres pontossággal tolja előre a céget a kívánt pozícióba.
A másik (általában IT-szakember) tábor szerint ezek ész nélkül minden szarba belekapnak, megveszik, beolvasztják, sokszor koncepció nélkül kitolják az ajtón, aztán várják, hogy mi lesz belőle.
Általában siker.

A Sun elmúlt években megváltozott koncepcióját én a második modellnek érzem. Kitalálták, hogy minden nyílt forrású lesz, jót fogunk csinálni olcsón, vagy ingyen, és ez majd faszán megment minket.
Tiszta Google. Csakhogy jött a "válság", így már sosem fogjuk megtudni, hogy ez a varázsgombák füstje alatt érlelődött koncepció működött-e volna, vagy sem, hiszen a szélvédő mögül már megpillantották a szakadék szélét, így sürgősen helikopterért SOS-eztek, hogy felemeljék őket, még mielőtt 9,81 m/s²-es gyorsulás indulna meg lefelé mutató vektorral (AKA szabadesés).
A legközelebbi helikopáter parancsnoka meg is hallotta a jajszót, és rögtön küldte is a csoppert, amely úgy tűnik sikeresen végrehajtja majd a .com-mandot, amelyben még a .eu-nuch sem tudja meggátolni, és habár a kötél még rezeg, még mindig nem tudjuk, hogy elszakad-e, vagy kitart a bázisig, a központban már javában (pun intended) tervezik, hogy mi legyen a megmentett ronccsal.
És nem csak tervezik, már ki is teszik a hirdetőtáblára, hadd tudják a kedves vásárlók, hogy a vélt Google-féle "leszarjuk a piaci igényeket, minden szemetet kirakunk az ablakba, vagyunk már akkorák, hogy végül mi alakítsuk a piacot" modellnek vége, innentől átkapcsolnak precíz halálosztó módba. Ami nem termel pénzt, az elsüllyed.
Sokan a MySQL-ért aggódtak(-nak), holott tényleg minek. Ha valóban fontos, túl fogja élni, az eltűnése miatt nem kell aggódni, legfeljebb csak GPL-es lesz, és kell majd egy BSD licencű MySQL kliens lib.
Az első érdekesebb hír tehát nem a MySQL-lel, hanem a szerverekkel kapcsolatos, konkrétan: "Kiszáll az olcsó tömegszerverek piacáról a Sun" (HUP, átvéve a HWSW cikkét).
Hogy ez pontosan mit jelent, még nem tudni, de Ellison mondata, amely úgy hangzik, hogy: "Az egyik dolog amit felismertünk, hogy a Sunnak nincs és valószínűleg sose lesz meg az a nagy volumene, ami versenyképessé teheti a tömegpiacon." elég sok találgatásra adhat okot, és nem csak az x86-os szerverek kapcsán, hanem úgy általában.
A Sun a pálfordulás után -ügyfél oldalról úgy tűnhet- a jó irányba fordult: meghallotta az ügyfelek igényeit, és elkezdett jó x86-os dobozokat gyártani megfizethető áron, normális konstrukciókban (lásd: a HP szerverekhez külön kell licencelni az ILO egyes funkcióit, a Sunnál minden alapáras), a szoftvertermékeit elindította a nyílt forráskód felé, amelyekhez supportot adott, a licencköltségek pedig viszonylag alacsonyak maradtak.

Larry mondatai azonban megijeszthetik a most elégedett ügyfeleket, és joggal, hiszen ezek az ügyfelek sokkal kevesebbet fizetnek azért, amit valójában kapnak (piaci alapon, a többiekhez mérve), amin sürgősen változtatni kell, pénzt kell termelni, hogy az (túlárazott?) akvizíció megtérüljön.

Mivel a blog logója egy Sun gépet ábrázol, úgy gondoltam elkészítem az új Oracle-Sun logót, illetve csinálok magamnak egy szép háttérképet is.

Kezdjük az új évet az új céggel, és logóval! SUNken, RIP.

BÚÉK!

Mást kerestem (becsszóra!) az images.google.com-on, de a találati listában megjelent ez a kép is. Rögtön a PostgreSQL replikáció jutott eszembe...

Bármennyire is szeretjük a FreeBSD-t, a hagyományos szerver-architektúrában gondolkozva egy igen komoly hátrányát sajnos a mai napig sem sikerült levetkőznie: HA clusterek építésére (osztott tárhellyel) nem igazán alkalmas.

Ez többek közt jelenti az olyan komplex megoldások hiányát, mint pld. Sun Cluster, de az olyan infrastrukturális "lyukakét" is, mint az osztott fájlrendszerek (pld. OCFS, QFS stb.), vagy a storage replikáció (pld. Linuxon a DRBD).

Nagyon nem kell örülni, shared file system úgy tűnik továbbra sincs útban (lehet, hogy mire idáig eljutunk, már nem is nagyon lesz rá szükség, hiszen aki olyan, lényegében "nem létező" OS-re épít komoly szolgáltatást, mint a FreeBSD, úgyis más -a feladatra alkalmasabb- módon oldja meg ezt a kérdést), közeledik viszont a HAST, azaz a High Availability Storage:

The software will allow for synchronous block-level replication of any storage media (GEOM providers, using FreeBSD nomenclature) over the TCP/IP network and for fast failure recovery. HAST will provide storage using GEOM infrastructure, which means it will be file system and application independent and could be combined with any existing GEOM class. In case of a master node failure, the cluster will be able to switch to the slave node, check and mount UFS file system or import ZFS pool and continue to work without missing a single bit of data.

A bejelentés szerint a projektet Pawel Jakub Dawidek (pár GEOM cucc, pld: eli, mirror, gate, label, journal, hsec stb., opencrypto, és persze a népszerű ZFS port) viszi, a szponzorálásába pedig a FreeBSD foundation mellett két cég is beszállt.

Egy december 13-i bejelentés szerint a fejlesztés jól halad, a HAST a geom gate alapjaira fog építeni.

Sokat kellett érte dolgozni, és várni, de végre megtörtént! Kevesebb, mint félmillió forintból 115 milliót csináltam kb. fél év alatt!

Értékpapír neve	Tulajdon mennyiség	Árfolyam(Ft/db)	Készlet árfolyamértéke (Ft)
AEGON ÁZSIA RÉSZVÉNY ALAP	535 946	214.5763	115 001 304

Évek óta natív IPv6 elérésre vágysz? Most már hamarosan a tiéd lehet, a Magyar Telekom ugyanis nyilvános IPv6 tesztet indít MT szolgáltatási területen (azaz az LTO-sok kimaradnak) lévő ADSL ügyfeleinek.

A szolgáltatást a jelenlegi DSL-es PPP userid után írt @ipv6.t-online.hu login névvel lehet használni, minden olyan klienssel, amely támogatja a PPPv6-ot. A Telekom alapból /64-es "kvázi fix" (ez valószínűleg azt jelenti, hogy mindaddig változatlan a /64-es prefix, amíg a routereken nem konfigurálnak poolokat) tartományt oszt, amelyből az IPv6 technológiának megfelelően a maradék /64-et a mi eszközünk "találhatja ki", illetve emellé kérhetünk egy /56-os tartományt is, amellyel végre elfelejthetjük a NAT-ot, és a router mögötti további otthoni eszközök is publikus IP címet kaphatnak.

A most indult tájékoztató oldalon részletes leírások találhatók Windows mellett linuxos környezetre is.

A Telekom már felkészítette a rekurzív névszervereit az IPv6-ra:

$ host cns0.telekom.hu
cns0.telekom.hu has address 84.2.44.1
cns0.telekom.hu has IPv6 address 2001:4c48:1::1
$ host cns1.telekom.hu
cns1.telekom.hu has address 84.2.46.1
cns1.telekom.hu has IPv6 address 2001:4c48:2::1

és úgy látszik, hogy az autoritatív NS-ek is v6-osítottak lesznek (majd valamikor):

$ host -t ns telekom.hu
telekom.hu name server ans1.t-online.hu.
telekom.hu name server ans0.t-online.hu.
$ host ans0.t-online.hu
ans0.t-online.hu has address 195.228.240.85
$ host ans0.telekom.hu
ans0.telekom.hu has address 195.228.240.85
ans0.telekom.hu has IPv6 address 2001:4c48:1:1::10
$ host ans1.telekom.hu
ans1.telekom.hu has address 195.56.77.76
$ host ans2.telekom.hu
ans2.telekom.hu has address 193.225.4.82
ans2.telekom.hu has IPv6 address 2001:738:0:100::

A fentiek szerint a most használt t-onlineos nevek helyett majd telekomosak jönnek, és -feltételezhetően azért, mert a Datanetnél hostolt másodlagos NS-nek a cég nem tudott közvetlen IPv6 elérést szerezni- újabb NS-sel bővül a pool, amely az NIIF-nél került elhelyezésre.

Sajnos az IPv6 access mit sem ér tartalom nélkül, a Telekom pedig úgy tűnik ebben még kevésbé aktív.

A saját (sűrűn használt, általam ismert, pld. origo, telekom.hu stb.) weblapjait tekintve még egyiknél sem találtam AAAA rekordot, viszont megjelent két direkt IPv6-os elérés:

$ host ipv6.freemail.hu
ipv6.freemail.hu has IPv6 address 2001:4c48:2:f::100
$ host ipv6.iwiw.hu
ipv6.iwiw.hu has IPv6 address 2001:4c48:2:a::1

Ezeket IPv6 elérés híján a SixXS v4-to-v6 HTTP proxyján keresztül tudjuk próbálgatni, pld. itt:

http://ipv6.freemail.hu.ipv4.sixxs.org/ http://ipv6.iwiw.hu.ipv4.sixxs.org/

Úgy látszik a cég egyelőre konzervatív hozzáállással közelít a v6-os DNS rekordok "normál" hostnévre pakolásában, ezt mutatják a fentiek is. Azonban sikerült találni olyan esetet is, ahol az A rekord mellé került be az AAAA, ez pedig nem más, mint a sima accesshez pakolt webtárhely:

$ host web.t-online.hu
web.t-online.hu has address 195.228.240.46
web.t-online.hu has IPv6 address 2001:4c48:1:1::13

azok tehát, akik itt hostolják weblapjukat már automatikusan IPv6-on is elérhetőek.

Logikus lépés lenne ha az IPv6-os access mellett a cég nagyobb hangsúlyt fektetne a protokollon elérhető tartalomra, ebbe pedig bevonná a nála (Adatpark) hostoló ügyfeleket is, akik egy része minden bizonnyal boldogan kapna az alkalmon, hogy új biztonsági lyukakat nyisson amúgy is tésztaszűrő-szerű UNIX-like OS-ein. Erre azonban a jelek szerint még várni kell, a témában annyi információt sikerült szereznem telekomos forrásból, hogy 2010-re várható az IPv6 hostingban való nyilvános megjelenése.
A nyilvánosat azért kell ide írni, mert van már olyan hosting-ügyfél, aki natív IPv6-on szolgáltat, hiszen egyik kedvenc oldalam, a HUP (és más FSN-es szerverek) is rendelkeznek már AAAA rekorddal, és v6-eléréssel:

$ host hup.hu
hup.hu has address 195.228.252.138
hup.hu has IPv6 address 2001:4c48:1:f800::6
$ host ftp.fsn.hu
ftp.fsn.hu is an alias for ftp.freepark.org.
ftp.freepark.org has address 195.228.252.133
ftp.freepark.org has IPv6 address 2001:4c48:1:f800::11
 

Ami azt illeti, elég régóta, hiszen egy, a HUP-ra írt cikk szerint már ezév március 24-én elérhetőek voltak ezek a hostok, a SixXS oldala szerint pedig 2009. 02. 11-én vált először IPv6-on láthatóvá a Magyar Telekom 2005-ben allokált IPv6 tartománya.

A fenti oldal tanúsága szerint jelenleg a következő magyar szolgáltatók rendelkeznek IPv6-os allokált prefixszel, és láthatóak is rajta:
BIX (ISzT), Pantel, Matáv, T-Mobile, ATW, EMKTV, Tarr, Externet, Deninet, Interware, HostOffice (az épp aktuális nevüket mindenki képzelje mellé).

Ezek közül legjobb tudomásom (google) szerint csak az Externet ad jelenleg otthoni IPv6 elérést, miután a hangzatos nevű "megérkezett az IPv6 Magyarországra" (totális blődség, legelőször talán a HBONE-NIIF-nek volt teljes körű, natív IPv6-os elérése Magyarországon, de FIXME) programmal berobbantotta az IPv6-ot az (r=1) köztudatba.

Az Externetnél túl sok infót nem sikerült találnom, a webszerverük viszont már elérhető IPv6-on:

$ host www.externet.hu
www.externet.hu has address 212.40.96.178
www.externet.hu has IPv6 address 2a02:558:0:120:212:40:96:178

Érdekes kérdés, hogy ha /64-et, illetve /56-ot adnak a szolgáltatók a usernek, vajon hogy biztosítják a PTR-ek (reverse DNS) hozzárendelését. A fenti tartományokból ugyanis a user dönti el, hogy a prefix mögé "mit tesz", azaz elvileg mind a 2^64, illetve 2^72 IP címre be kellene regisztrálni két rekordot (AAAA és PTR).

A legelterjedtebb autoritatív NS-ek (pld. bind, nsd) memóriában tartják a zónákat, így könnyen kiszámolható, hogy csak egyetlen userhez rendelt /64 és /56 összes AAAA és PTR rekordja annyi memóriát igényelne, amennyi valószínűleg storage-ból nem készült összesen mióta ilyeneket gyártanak. Nem jó tehát a diszk alapú tárolás (pld. az adatbázis alapú névszerverek) sem, marad tehát az, hogy nem adnak AAAA-t és PTR-t, vagy csak egy pár (általuk meghatározott címre adnak), vagy olyan névszervert használnak, amely adatbázis nélkül találja ki, hogy a beérkező hostnévre/IP címre mit kell visszaadni.

Kicsit Google-ztam a témában, de erre nem találtam best practice-t, viszont kerestem telekomos pool-címeket, és azt találtam, hogy ők lehet, hogy valami hasonlót csinálnak:

$ host bc24b9b7.dsl.pool.telekom.hu
bc24b9b7.dsl.pool.telekom.hu has address 188.36.185.183
$ host bc24b9b7.ktv.pool.telekom.hu
bc24b9b7.ktv.pool.telekom.hu has address 188.36.185.183
$ host bc24b9b7.dialup.pool.telekom.hu
bc24b9b7.dialup.pool.telekom.hu has address 188.36.185.183
$ host -t ns pool.telekom.hu
pool.telekom.hu name server pns1.telekom.hu.
pool.telekom.hu name server pns0.telekom.hu.

mivel nem valószínű, hogy ugyanazokat a hostokat az access típusától függetlenül statikusan több helyre is bedrótoznák, továbbá a SixXS lapon található mobilos tartományról megkérdezve a fenti pns nevű NS-eket:

$ host 2a00:1110:: pns0.telekom.hu

Host 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.1.1.0.0.a.2.ip6.arpa not found: 3(NXDOMAIN)
[...]

$ host 2a00:1110:8:: pns0.telekom.hu

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.0.0.0.0.1.1.1.0.0.a.2.ip6.arpa domain name pointer 2A001110000800000000000000000000.mobile.pool.telekom.hu.

$ host 2a00:1110:8:a:b:4:2:: pns0.telekom.hu

0.0.0.0.2.0.0.0.4.0.0.0.b.0.0.0.a.0.0.0.8.0.0.0.0.1.1.1.0.0.a.2.ip6.arpa domain name pointer 2A0011100008000A000B000400020000.mobile.pool.telekom.hu.

sikerült találnom egy tartományt, amelyre válaszol a gép, egy egyenválasszal (IP cím hexában), és minden véletlenszerűen kinézett címre jön ilyen, amit máshogy (szerintem) nem lehet megoldani, mint valami spéci NS-sel.

Ez alapján úgy tűnik, hogy a DSL mellett hamarosan jönnek a mobil IPv6-os címek is, amelyekre valószínűleg nagy szükség is van, hiszen az elérések száma rohamosan nő, és a T-Mobile-nál ráadásul már nem is NAT-olnak, azaz egyre szűkebb lehet a cipő, meg kell találni a kitörési lehetőséget valamiben (vagy újabb IPv4 tartományokat kell beszerezni, vagy visszaállni a NAT-ra).