--davrovy poznámky
kdo jinému jámu jámu, sám do ní sám...
| << | Jun 2013 | >> | ||||
| Mo | Tu | We | Th | Fr | Sa | Su |
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
IPv6 a komerční část univerzitní sítě
Tak jsme po mnoha letech vyčkávání konečně zažádali u RIPE-NCC o IPv6 adresy a jako LIR jsme dostali krásný prefix 2a00:5800::/32. (/32 je initial allocation size). Teď ještě zbývá vyřešit dva malé problémky: náš hlavní komerční router neumí IPv6 a nemáme ASN pro BGP (a navíc router v současnosti podporuje jenom 16 bitové ASN, a RIPE už nám patrně přidělí 32 bitové - kdo pozdě chodí, sám sobě škodí).
by David Rohleder : 2010/12/22 : Categories net : 0 trackbacks : 0 comments (permalink)
Listopad se nekoná?
Podle Ubuntu a Evolution asi ne.
 |
by David Rohleder : 2010/09/30 : 0 trackbacks : 0 comments (permalink)
Filesystémy - update
Tak jsem se znovu dostal k testování zápisu velkého souboru, tentokrát 5TB. Celková velikost disků je 8x 1TB v RAID5, což znamená celkem 7TB (6.99 TB/6.36 TiB) diskové kapacity.
Příkaz pro vytvoření souboru:
dd if=/dev/zero of=test.bin bs=1G count=5000 conv=sync
Debian testing ze 17.9.2010, jádro:
Linux test 2.6.32-5-amd64 #1 SMP Wed Aug 25 13:59:41 UTC 2010 x86_64 GNU/Linux
| filesystem | rychlost | poznámka |
| XFS | 274 MB/s | |
| BTRFS | 208 MB/s | |
| EXT4 | 181MB/s | |
| NILFS | 80.5 MB/s | |
| EXT3 | - | průběžně 161MB/s, pak file too large na 2043GB |
| JFS | - | průběžně 11MB/s, pak jfsCommit vytížil procesor na 99 % |
Vytvoření filesystému (bez speciálního nastavení):
time mkfs.[filesystém] /dev/sdb
| filesystém | real | user | sys |
| EXT3 | 30m23.647s | 0m2.224s | 1m27.177s |
| EXT4 | 16m15.333s | 0m7.880s | 1m35.678s |
| BTRFS | 0m0.030s | 0m0.008s | 0m0.004s |
| XFS | 0m9.016s | 0m0.000s | 0m0.272s |
| JFS | 0m4.885s | 0m0.120s | 0m1.100s |
| NILFS | 0m0.010s | 0m0.000s | 0m0.004s |
Překvapivě se tedy XFS mezi verzemi ještě zlepšil, EXT4 už nemá problémy s omezením velikosti souboru jako EXT3 a JFS je stále rozbité.
Vytváření EXT filesystémů je časově náročné, je vidět, že jsou to filesystémy, které patrně s tak velkými disky moc nepočítaly (nebo je jejich defaultní nastavení ne zcela optimální).
by David Rohleder : 2010/09/23 : 0 trackbacks : 0 comments (permalink)
Prostá věc - montování vfat v Gnome
Mám flashku z foťáku a na ní fotky. Foťák ty fotky ukládá s velkými písmeny, tj. IMG1234.JPG. Jenže já nemám rád velká písmena v názvech souborů. Samo o sobě to není problém, protože vfat je možné namontovat s přepinačem shortname=lower. Jenomže součástí Gnome jsou programy, které se starají o automatické montování svazků a další akce nad nimi. Přinutit Gnome, aby automaticky montovalo všechny svazky s volbou shortname=lower není už tak jednoduché, jak by se na první pohled mohlo zdát.
Protože montování svazku je privilegovaná operace, nemůže to udělat uživatel sám, ale musí se o to postarat část, která může provádět privilegované operace. Tento systém je složený z několika částí propojených různými komunikačními kanály:
udev - stará se hlavně o přidělení názvu zařízení v /dev
udisks (původně HAL - hardware abstraction layer, jehož vývoj byl zastaven a byl nahrazen balíkem DeviceKit-disks, který byl později přejmenován na udisks),
DBus - komunikační sběrnice mezi různými procesy
gvfsd - Gnome montovací démon
další - PolicyKit řídící oprávnění k privilegovaným operacím
 |
V praxi to vypadá následovně:
uživatel zasune flashku do čtečky, případně usb klíčenku do USB slotu
linuxové jádro předá přes netlink socket informaci o přidání nového hardware procesu udev
udev zjistí, o jaký hardware se jedná a vyrobí mu odpovídající záznam v /dev
udev informuje proces udisks o přidání nového svazku
udisks zjistí o jaký svazek se jedná a přes systémovou sběrnici D-BUSu o přidání svazku informuje všechny aplikace, které si přejí tyto informace dostávat. V případě Gnome je to gvfsd
gvfsd zjistí, že existuje nový svazek s určitým souborovým systémem, podle svého nejlepšího vědomí pak dá příkaz k přimontování daného svazku na některé místo ve filesystému - opět prostřednictvím zprávy přes systémovou sběrnici D-BUSu
této zprávy se ujme udisksd a přimontuje svazek na odpovídající místo (tady vstupuje do hry ještě kontrola oprávnění, o kterou se stará PolicyKit)
Svého času se gvfs přes gconf zeptal s jakými montovacími volbami má filesystém přimontovat (přes /system/storage/default_options/vfat/mount_options nebo /system/storage/název_disku/mount_options...)
Vývojáři Gnome se ale jednoho dne rozhodli, že každý uživatel je počítačově negramotný a svazky se budou montovat tak, jak uznají oni za vhodné a nikdy jinak (alespoň pokud nad tím mají kontrolu) a vazbu mezi gvfs a gconfem zrušili.
Chápu, že se vývojáři snaží mít uživatelsky přítulný systém, ale zrušení vazby mezi gvfs a gconfem považuju za velmi špatný nápad. Uživatelské rozhraní má být přítulné k začátečníkovi a zvolí vhodné bezpečné hodnoty, ale také k odborníkovi, který ví, co dělá a nebrání mu v dělání věcí, které od systému chce.
Doufám, že jednoho dne se konfigurace pomocí gconf nebo jiného podobného nástroje do systému vrátí. Netěší mne, že vývojáři UI takovým způsobem mrzačí možnosti toho, co může pěkně fungovat.
Nakonec jsem to vyřešil tak, že jsem upravil defaultní montovací přepinač v balíku udisks, přeložil a nainstaloval lokálně tuto upravenou verzi a bylo to. Ale systémové řešení to tedy není.
Zajímavé příkazy pro ladění případných problémů:
udisks --monitor-detail udisks --unmount /dev/sda1 udisks --mount-options "shortname=lower" --mount /dev/sda1 /media/disk gvfs-mount -oi gvfs-mount -u /media/disk /usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi dbus-monitor --monitor --system "interface='org.freedesktop.UDisks'"
by David Rohleder : 2010/05/08 : Categories ubuntu : 0 trackbacks : 0 comments (permalink)
Studenti bohatnou a mobilní, bezdrátová síť má ve špičkách přes 1000 uživatelů
Trvalo to několik let od zavedení bezdrátu na MU, aby se počet uživatelů bezdrátové sítě ve špičce přehoupl přes tisíc současně pracujících. V součtu nejsou zahrnuty některé fakulty, které nepoužívají univerzitní bezdrátovou infrastrukturu (FI, PřF).
by David Rohleder : 2010/03/17 : Categories net : 0 trackbacks : 0 comments (permalink)
Filesystémy a velký soubor
Mám takové menší diskové pole, 7x 1TB disků na řadiči 3ware Inc 9650SE SATA-II RAID, tak jsem si před jeho zapojením chtěl vyzkoušet, jak jsou jednotlivé filesystémy rychlé. Jeden z testů byl, jak rychle je možné zapsat na disk opravdu velký soubor - 3TB:
dd if=/dev/zero of=/storage/test.bin count=3000 bs=1G
Výsledky filesystémů vypadají následovně:
| filesystem | rychlost | poznámka |
| XFS | 221MB/s | |
| EXT3 | - | průběžně 120MB/s, pak file too large na 2043GB |
| JFS | - | průběžně 11MB/s, pak jfsCommit vytížil procesor na 99 % |
Debian 5.0, žádné speciální úpravy. Zajímavé, jak jsou ty filesystémy nepoužitelné.
by David Rohleder : 2010/03/04 : 2 comments (permalink)
Vitráž
Sice jsem se u toho popálil, jak jsem šikovný, ale výsledek stojí za to.
 |
by David Rohleder : 2010/02/21 : 0 trackbacks : 1 comment (permalink)
Vypnutí staré páteře a nedostupný Internet
Je to takový... nemilá věc, bych řekl. Člověk iniciativně vypne poslední krabici staré páteře, na kterou už není nic připojeno a ono to způsobí nedostupnost celého Internetu. Ale pěkně popořádku.
Ve středu večer jsem vypnul tři směrovače na našem sále, dva z nich připojovaly servery, které už jsme přemigrovali někam jinam, poslední byl bývalý hlavní přípoj do Internetu. To všechno prošlo hladce, drobné chybky, které se vyskytly jsem opravil. Ve čtvrtek okolo 10h jsem zavolal na PřF, že mohou vypnout i poslední směrovač staré páteře. Vypnuli a za chvíli to začalo. Celá síť MU zmizela z Internetu. Problém byl v konfiguraci BGP, tedy přesněji tam, kde se generovala síť 147.251.0.0/16 do BGP.
Při budování nové páteře jsme totiž postupovali následovně. Nainstalovali jsme směrovače nové páteře a propojili jsme starou páteř s novou. Následně jsme přepojili linku do CESNETu na směrovač nové páteře. Nicméně NLRI pro síť 147.251.0.0/16 jsme nechali generovat směrovače staré páteře. A to z jednoho jednoduchého důvodu. Při přepojování jednotlivých připojených sítí do nové páteře jsme prostě pouze přehodili linku ze starého směrovače do nového. V případě, že přišel paket z CESNETu do nové páteře, tak pokud byla síť v nové páteři, tak o tom nová páteř věděla a poslala paket na místo kam patří. V případě, že tuto síť neměla připojenou, poslala ji do staré páteře, protože směrovač staré páteře generoval NLRI pro celou 147.251.0.0/16 (tato cesta se uplatnila v nové páteři, pokud neexistovala v routovací tabulce síť s větší netmaskou).
Postupem času jsme přesunuli všechny sítě do nové páteře a bylo tedy možné vypnout starou páteř. Jenže v této chvíli nastal problém, který vedl k výpadku. Ačkoliv se v BGP na naší páteři šíří všechny sítě, tak směrem do CESNETu se šíří pouze celá síť 147.251.0.0/16 (není důvod šířit něco jiného, protože všechny sítě musí projít přes stejný bod). Ve chvíli, kdy jsem vypnul poslední směrovač generující celou síť MU se do CESNETu přestala šířit tato cesta a všechny ostatní cesty byly vyfiltrované. MU tedy zmizela z Internetu. Chvíli nám trvalo, než jsme si uvědomili, v čem je problém a než se nám podařilo napsat pouhé dva řádky, které uvedly všechno do správného stavu.
router bgp XXXXX network 147.251.0.0 mask 255.255.255.0 ip route 147.251.0.0 255.255.0.0 Null 0 250
(podobného chování lze dosáhnout několika způsoby, např. šířením agregované sítě - k tomu bychom ani nepotřebovali tu statickou cestu na posledním řádku)
Poučení na konec: všechno souvisí se vším.
by David Rohleder : 2010/02/11 : Categories net : 0 trackbacks : 0 comments (permalink)
FI opět s IPv6
FI MU vyrazila moderním směrem a nechala si zprovoznit přidělený IPv6 prefix a tím se opět zařadila mezi pozdní průkopníky IPv6 na univerzitě. A když zprovozní i IS, tak vyřeší dlouholetý IPv6 problém vejce/slepice. Zdravíme Yenyu, IPv6 průkopníka :-)
by David Rohleder : 2010/02/10 : Categories net : 0 trackbacks : 0 comments (permalink)
HP kupuje 3Com
Tak HP vytáhlo nějaké drobné a koupilo 3Com.
Poměrně zajímavá zpráva, zvlášť když používáme produkty obou firem. HP koupilo 3Com zřejmě i s H3C. Poslední kousky od 3Com (spíš tedy rebrandované H3C) vypadají dost dobře.
Osobně bych si tipoval na postupný konec řady HP Procurve. Byla by to dobrá volba, 3Com na tom byl v síťování asi lépe než HP. Uvidíme, jak se to vyvrbí, ale v řadách levnějších switchů už si patrně nebudeme muset vybírat mezi těmito dvěma zmíněnými firmami.
by David Rohleder : 2009/11/16 : Categories networking : 0 trackbacks : 4 comments (permalink)