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!

ZFS pool-verziók, és azok új funkciói. Hasznos lehet az eligazodáskor a ZFS-káoszban:

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

Indexék cikket írnak "Kis ország, kis Google" címmel. A szerző a beavatottság és a top secret klasszifikáció légkörét idéző gondolatmenettel túráztatja a billenytűzetét, és csigázza az olvasó kíváncsiságát, amely körmeit rágva vár arra, hogy most végre megtudja az igazságot az UFO, izé a Google magyarországi szerverparkjáról (1, vagy 0, TRUE, vagy FALSE?):

[...] kivéve talán azt a vicces álláshirdetést, amelyben 8-10 kilogrammos tárgyak felemelésére is képes erőembereket keresett, nem sokkal a cégbejegyzés után.

Az éles eszű megfigyelők rögtön arra gondoltak, hogy a Google Magyarországon is felállít egy szerverparkot, mert mi másra kellene neki erőember, de hogy vannak-e a Google-nek szerverei itthon, az máig titok: a cég munkatársai szerint az infrastruktúrát úgy építették meg, hogy mindegy, vannak-e az országban a keresést és az alkalmazásokat kiszolgáló gépek, vagy nincsenek. "Lehet, hogy egy szerverpark sincs Magyarországon, de lehet, hogy három is van" – válaszolták a múlt héten az Index kérdésére.

Most persze mondhatnám, hogy hvazzeg Mártikám, minden nap a Google-höz megyek 8-10 kilogrammos tárgyakat emelgetni -és már kurvára unom, mert a hiedelmekkel ellentétben ezzel a Google-nél sem lehet BKV-s jövedelmeket kapni-, és ilyeténformán a saját fél (ép, a másikat kiszúrta egy kiálló Google-szerver éles sarkú alaplapja) szememmel láttam, hogy igenis van Magyarországon Google szerverpark. Sőt, nem csak láttam, de éreztem is, a Google szerverparkjában ugyanis -az itteni irodai dolgozók munkahelyével ellentétben, ami szimpla, és unalmas- ugyanolyan kreatív megoldások vannak, mint a külföldi Googleplexekben.
Mert hát az irodistákkal ellentétben az, hogy a szerverek jól érezzék magukat kiemelt fontosságú, így van nekik csúszda, amivel az első emeleti gépteremből a földszintibe csúszhatnak, ha fent megállna a router, van akvárium, amiben nézhetik a halakat a kádból (ez egyébként csak a you tub szerverek kiváltsága), és van pingpongasztal az ICMP könnyebb gyakorlásához, stb.

De persze nem mondom, mert akkor kiszúrják a másik szemem is.

Ja és az érzés: a Google hazai szerverparkjában Vint Cerf "v4" típusú dezodorral illatosítanak minden félórában! Bár állítólag ez már nem sokáig megy tovább, mert lassan kifogy, újabbat meg ebből már nem gyártanak, de majd jön a következő "v6" illat. Izgatottan várom, szeretem ezt a határozott, karakteres illatot.

Kicsit szégyellem bevallani, de otthonra is loptam már ilyet, hiába a nyomdában lehúzott évek nem múltak el nyomtalanul -éérted- (csak ott még a pornót loptuk, itt meg az illatot). Teljesen feldobja a lakást, és mindenki irigykedve kérdezi, hogy mi ez, mire büszkén felelhetem, hogy: a Google illata!

A barátnőm avonos barátnői, és az én amwayes ismerőseim is epekednek utána, de ilyet akárhogy is törik magukat, nem tudnak beszerezni a nyamvadt MLM ügynöküktől!

Na szóval mivel nem mondhatom, inkább mutatom. Jól figyeljetek, most kiderül minden!

Először is a ping. A www.google.com néhány helyről olyan közel van, hogy nem lehet távol. Tudjátok, lehet a Google-nek sok pénze, vehet terabiteket minden kontinensre, de Amerika innen a távoli Balkánról akkor is kurva messze van. A fény meg lassú, de az elektronok sem gyorsabbak. A Szub-Éta meg még csak a Galaxis Utikalauzban van.

Szóval az még jó eséllyel az otthoni csellóról is kiderül, hogy a www.google.com közelebb van, mint a mail.kisbőgő.hu. Ez meg már gyanús (már látom, körvonalazódik a fejekben a következő cikk, amelyben lerántják a leplet a kék articsókás cégről, hogy az alig létezik Magyarországon, ami itt látható az csak egy transzdimenzionális szubtrakció az ottani végtelen kapacitásrengetegből).

Még gyanúsabb, ha valami jobb helyről próbáljuk, mondjuk pár szerverhosting szolgáltatótól, mint például:

 2  GE-0-0-12.border0.interware.hu (195.70.32.4)  1.006 ms  0.649 ms  0.993 ms
 3  bpt-b2-link.telia.net (213.248.103.105)  0.980 ms  0.713 ms  0.977 ms
 4  bpt-b1-link.telia.net (80.91.250.64)  1.981 ms  1.674 ms  0.968 ms
 5  ffm-bb2-link.telia.net (80.91.247.54)  20.981 ms  20.697 ms  19.981 ms
 6  ffm-b7-link.telia.net (80.91.254.253)  20.984 ms
    ffm-b7-link.telia.net (80.91.251.234)  20.676 ms *
 7  google-118152-ffm-b7.c.telia.net (213.248.102.234)  18.976 ms
    google-ic-127675-ffm-b7.c.telia.net (213.248.89.42)  19.653 ms
    google-ic-127674-ffm-b7.c.telia.net (213.248.89.38)  28.681 ms
 8  209.85.255.176 (209.85.255.176)  19.778 ms
    209.85.255.178 (209.85.255.178)  19.747 ms  18.743 ms
 9  72.14.236.250 (72.14.236.250)  18.970 ms
    72.14.232.103 (72.14.232.103)  18.740 ms  18.771 ms
10  209.85.248.39 (209.85.248.39)  18.941 ms  19.692 ms
    209.85.248.43 (209.85.248.43)  18.974 ms
11  72.14.238.101 (72.14.238.101)  18.731 ms
    72.14.232.217 (72.14.232.217)  18.757 ms
    72.14.238.105 (72.14.238.105)  30.745 ms
12  hb-in-f99.google.com (74.125.87.99)  19.744 ms  19.662 ms  18.980 ms

Ja, bocs, nem, kivétel erősíti a szabályt, de:

  2  TenGE-7-1.hubud.datanet.hu (194.149.20.253)  0.296 ms  2.889 ms  0.718 ms
 3  74.125.50.141 (74.125.50.141)  0.572 ms  0.555 ms  0.572 ms
 4  209.85.242.228 (209.85.242.228)  0.717 ms  0.660 ms
    209.85.242.230 (209.85.242.230)  0.712 ms
 5  209.85.248.41 (209.85.248.41)  0.674 ms
    209.85.248.39 (209.85.248.39)  0.818 ms
    209.85.248.47 (209.85.248.47)  0.792 ms
 6  72.14.238.101 (72.14.238.101)  13.492 ms
    72.14.232.221 (72.14.232.221)  5.640 ms  13.230 ms
 7  hb-in-f99.google.com (74.125.87.99)  1.292 ms  1.134 ms  1.016 ms

és:

 3  84.1.104.212 (84.1.104.212)  0.459 ms  0.362 ms  0.416 ms
 4  google.osr1-dataplex.net.telekom.hu (81.183.247.98)  0.648 ms  0.698 ms 0.662 ms
 5  209.85.242.228 (209.85.242.228)  0.662 ms
    209.85.242.230 (209.85.242.230)  0.702 ms  7.555 ms
 6  209.85.248.39 (209.85.248.39)  0.664 ms
    209.85.248.47 (209.85.248.47)  0.709 ms  0.877 ms
 7  72.14.238.105 (72.14.238.105)  0.971 ms
    72.14.232.217 (72.14.232.217)  3.633 ms
    72.14.238.105 (72.14.238.105)  1.138 ms
 8  hb-in-f99.google.com (74.125.87.99)  1.134 ms  1.286 ms  1.285 ms

Azt mondja, hogy google.osr1-dataplex. Nahát, ezek szerint nem csak az derült ki, hogy van Google szerverpark Magyarországon, hanem az is, hogy a Dataplexben van. És még csak oda sem kellett mennünk. Hol tart már a technika!

De lehetünk még tudományosabbak: a minimum RTT 1,016 ms. Ez azt jelenti, hogy az ICMP kérés elküldése és a válasz megérkezése között legfeljebb kb. 1 ms telik el.

Ez azt jelenti, hogy ha az adatutak szimmetrikusak, 0,5 ms-ba telik az információnak, míg odaér. Ebben persze benne van sok minden, például az információ sem nulla hosszú, illetve a fizikai továbbításhoz képest az eszközök okozta késleltetés (router kitalálja, hogy mi legyen, rossz esetben a route táblája alapján (ilyen elég sokszor volt, ahogy fent is látszik), jó esetben valami alacsonyabb réteg alapján (pld. MPLS, amely hopjait itt nem láthatjuk), checksumot ellenőriz, TTL-t csökkent, stb).
Legyünk jóindulatúak, és állítsuk azt a természettől elrugaszkodott elképzelést, hogy a hálózati eszközök semmit sem késleltetnek.

Ez esetben (299792458/1000)*(1,016/2)=152294, azaz a fény által megtett út 1 ms-ra vetítve, szorozva a RTT felével kiadja a maximális úthosszt, azaz 152 km-t.

A Google szerverei tehát Budapesttől legfeljebb 152 km-re vannak, azaz nagy eséllyel Magyarországon. Valójában persze az átvitel ennek kb. tizede (vagy még annyi sem), így a 152 km inkább 5-15 km, a többi a csomagfeldolgozás késleltetése.

Ennyi matek épp elég is volt mára, így búcsúzom is. Holnap korán kell kelni, és sok 8-10 kilogrammos tárgyat kell még emelnem.

Feküdjön tehát mindenki azzal a boldog tudattal, hogy van Google szerverpark Magyarországon!

Juhéj!

A korábbi cikkekből megtudhattuk hogy teljesít a MySQL FreeBSD-n, és hogy mennyit gyorsult a 8-as kiadással a 7-eshez képest. De ez elég vajon ahhoz, hogy a Linuxot és az OpenSolarist lekörözze?

Íme:

A sysbench read-write teszten a Linux (ext3-mal, lásd korábbi cikket, ez adja Linuxon a legnagyobb teljesítményt) keményen otthagyja a FreeBSD-t és az OpenSolarist. A FreeBSD 64 szálig képes ráverni a Solarisra, de utána egy erősebb visszaesés következik, ahol az OpenSolaris kiengyensúlyozottabb teljesítményt képest nyújtani.

Ugyanez a read-only tesztekben a következőképpen alakul:

Az eredmények hasonlók, bár az OpenSolaris hamarabb veszi át a dobogó második helyét a FreeBSD-től, mint a RW tesztnél.

Konklúzió: a Linux visszavette a FreeBSD-től az elsőséget annak ellenére, hogy ez utóbbi is jelentős fejlődésen ment keresztül. Az OpenSolaris ugyanabban cipőben jár teljesítmény szempontjából, mint a FreeBSD, ha pedig megnéznénk a Solaris 10-et valószínűleg hasonló eredményeket látnánk, azaz a FreeBSD hetes és nyolcas kiadása kb. úgy arányulna egymáshoz, mint a Solaris 10 és az OpenSolaris.

Íme a világ legjobban fizetett vállalatvezetői 2008-ban:

Larry Ellisont nem kell bemutatni, hiszen aki eddig nem találkozott vele, most már a csapot megengedve is őt hallhatja, amint próbálja meggyőzni a nagyközönséget (Európát), hogy cége egyesülése a Sunnal jó lesz mindenkinek.

Az ábráról nem csak azt tudhatjuk meg, hogy a főemberek mennyi milliót tettek zsebre, hanem azt is, hogy ebből a pénzből hány minimálbéren élő embert lehetne eltartani... az USA-ban.

Nálunk persze nem 15.081 (amerikai) dollár, azaz 227.795 forint a havi minimálbér, hanem 69 ezer forint (2008-as adat), így a jól kereső felsővezetők zsámolyain szereplő számokat 3,3-del kell szorozni, azaz kedvencünk, Larry Ellison tavalyi pénzéből 18509 magyar minimálbérest lehetne eltartani.

A többit meg úgyis zsebbe kapják...

A Linux sok területen a választásról szól. És most nem arra gondolok, hogy nem muszáj használni, lehet mást telepíteni. :)

Fájlrendszer fronton számos lehetőségünk van, amelyek között sokan személyes preferencia (ezt ismerem, ezt szeretem) alapján választanak. De vajon melyik fájlrendszer teljesít a legjobban MySQL alatt?

Nézzük:

A fájlrendszerek a standard beállításaikkal lettek megformázva, a hardver és szoftverkörnyezet a korábbiakban említett (MySQL és PostgreSQL történelem cikkek).

Meglepő, hogy az ext3 ilyen fölényesen gyaláz mindenkit, a feltörekvő, új generációs FS-ek (btrfs, ext4) pedig mennyire rosszul teljesítenek...

A MySQL és PostgreSQL történelem cikkek alapját képező adathalmaz további elemzése közben újabb grafikonok születtek. Ezek a MySQL és a PostgreSQL viselkedését mutatják FreeBSD (8) alatt, UFS és ZFS háttértáron. A (szoftver és hardver) konfiguráció változatlan, a MySQL-nél viszont két mérés is készült, amelyek között az eltérés a MySQL innodb_flush_log_at_trx_commit opciójában volt.
Az egyik esetben ennek értéke egy volt (ACID-compliant, minden tranzakció után flush), a másikban kettő (másodpercenkénti flush a logokon).

MySQL:

Mint látható, a MySQL-t nagyrészt hidegen hagyja, hogy a fenti opció mire van állítva, sőt, az elvileg rosszabb teljesítményt adó 1-es értéknél 512 szálnál erős kiugrás látható.
Látszik továbbá, hogy az UFS és a ZFS közt elhanyagolható különbség van.
Ezek valószínűleg annak köszönhetők, hogy a két 15kRPM-es SAS diszk egy BBWC-s RAID vezérlőn csücsültek, az írás pedig nem volt annyira durva, hogy a ZFS dupla írását (journaling, ZIL) és a sűrű syncelést, vagy az UFS egyszeres írását és syncelését ne tudja "elkenni", és azokat gyorsan a cache-be tömni, majd visszaigazolni az OS-nek.

Ugyanez PostgreSQL-lel már kicsit szomorúbb képet fest:

A PostgreSQL alapból a MySQL fenti beállításának egyes értékét használja (fsync minden tranzakció után). Megfigyelhető, hogy ha valaki PostgreSQL-t szeretne ZFS-en használni, érdemes utánaolvasnia mind a ZFS, mind pedig a PostgreSQL működésének, ha valami teljesítményhez hasonlót ki szeretne húzni a rendszeréből.

Természetesen ez minden más esetben sem árt...

Itt van ez az indexes cikk a második nagy telekomos hálózati meltdownról.

A néha meg-megváltozó cikk mostani állapotában például ezt olvashatjuk:

Olvasóinktól annyit tudunk, hogy a Magyar Telekom adatközpontjában, a Datacenterben lévő weboldalak közül több elérhetetlenné vált, és hogy sok felhasználó panaszkodik az akadozó internetelérésre.

A Magyar Telekom sajtóosztályától elmondta, hogy péntek délután 16 óra körül az ügyfeleik egy része valóban tapasztalhatott problémát az internet elérésben. A szakértők intézkedtek, és 17 óra előtt a szolgáltatások már működtek.

(kiemelések tőlem) "a Datacenterben", ezen könnyesre röhögtem magam, de nem is ez a legjobb, hanem a cikk végén felejtett reklám:

A cikk T-Mobile szélessávú eszközök segítségével készült. (x)

Elképzeltem, hogy miközben "a Datacenterben" a routerek épp azon gondolkoztak, hogy most akkor merre is menjenek azok a fránya csomagok, meg a DNS szerverekkel is volt valami kefe, szóval eközben a mit sem sejtő indexes kollegák "T-Mobile szélessávú eszközök segítségével" írják bőszen a cikket. A Magyar Telekom hálózatából.

Kb. ennyire szenzációhajhász szokás szerint az egyik nagy magyar hírsite (amely többször változtatott már a cikken, lassan csurog az info, ha nincs internet, na :).

A HUP-on (szintén szokás szerint) viszont már pontosabb információk keringenek:

( Hunger | 2009. október 9., péntek - 17:17 )

Állítólag leszakadt T-com, Hungarnet, UPC is a BIX-ről, mert túl alacsony prefixlimitjük volt.

 ( gax_colos | 2009. október 9., péntek - 19:01 )

A T -nél igen, :)

A Hungarnet forgalmában drámai visszaesés nem látható:

A UPC viszont már jobban megszenvedte a dolgot:

De a legdurvább változás a Magyar Telekom BIX kapcsolatában mutatkozik, amely gyakorlatilag szummában is nullára esett, azaz a private peeringeket nem számolva leszakadt a magyar internetről, hogy a haza forgalmát a nemzetközi uplinkeken cserélje ki a többi szolgáltatóval:

Ez elvben túl sok problémát nem is kellett volna, hogy okozzon, azonban a T nemzetközi kapcsolatainak telítődése (valószínűleg azért sok van neki, az sem kizárt, hogy a BIX felé menő forgalom is elférjen rajta), és a többi hazai ISP limitáltabb nemzetközije olyan belassulást eredményezhetett, amitől sok minden szenvedett.

A zárt körű BIX levelezőlistáról származó információk alapján pár nappal ezelőtt (október 5-én) a BIX üzemeltetője tájékoztatta a BIX-tagokat arról, hogy egy új tag (AS9002, RETN) fog csatlakozni a BIX route szervereire, amely miatt a most kb. 5e-es prefix lista 9 ezresre fog nőni, és ez problémát okozhat pár routernél.

Ez a levél azonban "elakadt" a listaszerveren, így a BIX-tagok nem kapták meg. A BIX üzemeltető a levelet ma (16:20-kor) újraküldte (nézzünk csak egy kicsit feljebb...), kiegészítve némi infóval arra vonatkozóan, hogy ez hol okozhat még problémát (időközben kiderült?).

Az, hogy a legtöbb szolgáltató lazán átvészelte ezt az új helyzetet, a Magyar Telekom routerei viszont teljesen behaltak tőle azért felvet pár érdekes kérdést...

A ZFS ARC (Adaptive Replacement Cache, az IBM "találmánya") valósítja meg a fájlrendszer cache-t, azaz a sűrűn használt objektumokat igyekszik memóriában (vagy az L2ARC esetében valamilyen, a diszkeknél gyorsabban elérhető -pld. SSD- médián) tartani.

Az ARC külön válik a unified(VM) buffer cache-től, így a FreeBSD-n (is) sok problémát okozott a kezdeti időkben, a kis memóriával rendelkező (jellemzően 32 bites) gépeken a leggyakoribb probléma a kernelmemória elfogyása volt, amit az ARC és a kmem méretének gondos beállításával lehetett többé-kevésbé orvosolni.

A probléma kezelésére született meg még májusban az a FreeBSD commit, amely lehetővé teszi a VM számára, hogy ha memóriára van szüksége, visszavegyen a ZFS ARC-tól.

Sajnos ezzel viszont teljesen más problémák jöttek elő. A ZFS cache mérete egy ideig nőtt, majd -olyan esetekben is, ahol ez amúgy indokolatlan- drasztikusan csökkent, ahogy az alábbi képen is látni lehet:

A problémát többen felvetették, és visszaigazolták (a grafikon is egy ilyen bejelentésből származik), pld. itt és itt, a megoldás viszont váratott magára, annak ellenére, hogy Kip Macy, az egyik ZFS fejlesztő is elismerte a hibát.

Jó hír tehát azoknak, akik ettől a hibától szenvedtek, hogy (elvileg) végre megszületett a megoldás, amely lehetővé teszi a kernelnek, hogy visszavegyen a ZFS ARCából, de megakadályozza, hogy ez feleslegesen történjen.

A csecsemőhalált halt MySQL 6.0 újdonsága lett volna a Falcon storage engine, amely az ígéretek szerint "lightning fast, large memory, multi-cpu aware".

24 mag, 128 GiB RAM eléggé multi-cpu (jó, az UltraSPARC CMT-khez képest nem, és persze itt sem CPU-kból, mintsem magokból van sok) és large memory, nézzük meg mit tud ezen a MySQL!

Az Oracle-akvizícióval teljesen logikusnak tűnik, hogy a cég pénzt fektessen egy olyan ki-, vagy továbbfejlesztésébe, amellyel egyébként már rendelkezik (InnoDB, Berkeley DB), így hát könnyen megeshet, hogy most találkozunk utoljára a sólyommal. Temessük méltósággal, ha kell valakinek, úgyis kimászik a föld alól.

A képen a 6.0.11-es verzióban lévő InnoDB és Falcon engine küzd a felturbózott 5.4.1-es InnoDB-jével. Mint látszik, a Falcon a 6-os verzióban 32 szálig konzisztensen alatta marad az InnoDB-nek, de 32 szál felett már látszik valami teljesítmény.

Sajnos ez pont semmit sem ér az 5.4-ben meghegesztett InnoDB-vel szemben. Természetesen az InnoDB-t összehasonlítani az alfa verziós Falconnal nem biztos, hogy igazságos, de hát ez van, hasonlítanám én a GA-hoz is, ha lenne olyan...

Read write fronton a grafikon eképpen néz ki:

A Falcon itt sem kápráztat el minket, de legalább kiegyensúlyozottabban lassú, mint az InnoDB. Ez is egy eredmény...

Téteket, fogadásokat: lesz-e falcon/maria a MySQL-ben? Lesz-e MySQL? :)

Firmware frissítés HP szerveren. Rutinfeladat. De most az egyszer nem.

Indulás után a következő fogad:

FATAL ROM ERROR: The System ROM is not Properly Programmed

 No para, ezért van a backup system ROM. Mindjárt ki is írja, hogy azzal bootol...

... majd pár másodperc múlva...

... a következő bootnál...

... ha resetelem, azt fogja bootolni...

... ha kikapcsolom, azt fogja bootolni...

MIKOR FOGJA AZT A ROHADT BACKUP ROM-OT BOOTOLNI?!

Manual elővesz, megnéz mi a teendő ilyenkor. Azt mondja, hogy:

FATAL ROM ERROR: The System ROM is not Properly Programmed.
      Audible Beeps: 1 long, 1 short
      Possible Cause: The System ROM is not properly programmed.
      Action: Replace the physical ROM part.

B+. Google. Azt mondja, hogy nyomjak F9-et, majd a BIOS-ból válasszam ki, hogy az előző ROM-ot szeretném bootolni. DE NINCS BIOS!

Aztán ráakadtam erre:

To Boot to a Backup ROM:

To access the redundant ROM through RBSU:
1. Access RBSU by pressing the F9 key during powerup when the prompt is displayed in the upper right corner of the screen.
2. Select Advanced Options.
3. Select Redundant ROM Selection.
4. Select the ROM version.
5. Press the Enter key.
6. Press the Esc key to exit the current menu or press the F10 key to exit RBSU. The server restarts automatically.


To access the redundant ROM manually:
1. Power down the server
2. Remove the access panel
3. Set positions 1, 5, and 6 of the system maintenance switch to On.
4. Install the access panel
5. Power up the server
6. Wait for the server to emit two beeps.
7. Repeat steps 1 and 2.
8. Set positions 1, 5, and 6 of the system maintenance switch to Off.
9. Repeat steps 4 and 5.

(az első értelemszerűen NO GO nálam)

Eljátszottam, vártam a két bip-et. Nem volt. Kezdtem aggódni. A biztonság kedvéért vártam kb. négy percet, majd folytattam.

A poweron után lélegzetvisszafojtva vártam az eredményt.

HP logo... Szünet. Indul!

Huh.