UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-1.2 a 20.04 OTA-12.
Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.0 otevřeného operačního systému pro chytré hodinky AsteroidOS (Wikipedie). Přehled novinek v oznámení o vydání a na YouTube.
WoWee je open-source klient pro MMORPG hru World of Warcraft, kompatibilní se základní verzí a rozšířeními The Burning Crusade a Wrath of the Lich King. Klient je napsaný v C++ a využívá vlastní OpenGL renderer, pro provoz vyžaduje modely, grafiku, hudbu, zvuky a další assety z originální kopie hry od Blizzardu. Zdrojový kód je na GitHubu, dostupný pod licencí MIT.
Byl představen ICT Supply Chain Security Toolbox, společný nezávazný rámec EU pro posuzování a snižování kybernetických bezpečnostních rizik v ICT dodavatelských řetězcích. Toolbox identifikuje možné rizikové scénáře ovlivňující ICT dodavatelské řetězce a na jejich podkladě nabízí koordinovaná doporučení k hodnocení a mitigaci rizik. Doporučení se dotýkají mj. podpory multi-vendor strategií a snižování závislostí na vysoce
… více »Nizozemský ministr obrany Gijs Tuinman prohlásil, že je možné stíhací letouny F-35 'jailbreaknout stejně jako iPhony', tedy upravit jejich software bez souhlasu USA nebo spolupráce s výrobcem Lockheed Martin. Tento výrok zazněl v rozhovoru na BNR Nieuwsradio, kde Tuinman naznačil, že evropské země by mohly potřebovat větší nezávislost na americké technologii. Jak by bylo jailbreak možné technicky provést pan ministr nijak nespecifikoval, nicméně je známé, že izraelské letectvo ve svých modifikovaných stíhačkách F-35 používá vlastní software.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 162 (pdf).
Sdružení CZ.NIC, správce české národní domény, zveřejnilo Domain Report za rok 2025 s klíčovými daty o vývoji domény .CZ. Na konci roku 2025 bylo v registru české národní domény celkem 1 515 860 s koncovkou .CZ. Průměrně bylo měsíčně zaregistrováno 16 222 domén, přičemž nejvíce registrací proběhlo v lednu (18 722) a nejméně pak v červnu (14 559). Podíl domén zabezpečených pomocí technologie DNSSEC se po několika letech stagnace výrazně
… více »Google představil telefon Pixel 10a. S funkci Satelitní SOS, která vás spojí se záchrannými složkami i v místech bez signálu Wi-Fi nebo mobilní sítě. Cena telefonu je od 13 290 Kč.
Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Fedora 43 Asahi Remix s KDE Plasma už funguje na M3. Zatím ale bez GPU akcelerace. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
Red Hat představil nový nástroj Digital Sovereignty Readiness Assessment (GitHub), který organizacím umožní vyhodnotit jejich aktuální schopnosti v oblasti digitální suverenity a nastavit strategii pro nezávislé a bezpečné řízení IT prostředí.
Našel by se tu někdo, kdo má zkušenosti s provozem něčeho podobného? V mém případě se jedná o storage Dell MD3000i, což by měl být stejný HW jako IBM DS4000.
Jak jsem zmínil přistupuji k němu přes iSCSI porty, které má celkem 4. Mám k němu připojené dva servery na přímo (tzn. do každého serveru dva porty). Víceméně tato konfigurace funguje, pokud pominu chyby, které jsou podle Dellu "normální" - v konzoli se při připojení na portál anebo listování disků objevují I/O chyby 20MB LUNu, který je pro nějaké zvláštní účely.
Můj problém tkví v tom, že když vypnu jednu ze síťovek:
1) v době kdy se na úložiště nepřistupuje, multipath zareaguje během 20 s
2) v době, kdy na úložiště zapisuji, multipath zareaguje po více než minutě
Pokud sleduji stav sessions příkazem iscsiadm -m session -P 2,tak v prvním případě je vidět, že ztrátu zaznamená za méně než 10 s. V druhém ale čekám téměř minutu. Testy jsem prováděl při zápisu v jednom threadu, nevím tedy, zda se čas prodlužuje s více souběžnými operacemi...
V iscsid.conf mám nastaveny všechny timeouty velmi nízko. Tak trochu z toho podezírám modul rdac (který zde slouží ke kontrole cest) protože v sobě má nastavený nějaký timeout na 60000 ms.
Měl by někdo nějaký nápad nebo malinkou myšlenku? Mám totiž obavy, že kdyby všechny virtuální stroje musely při problému čekat minutu až dvě než se vzpamatuje disk, tak by dříve popadaly...
Jediné co mne napadlo je, zkompilovat si modul dm-rdac s upraveným timeoutem ve zdrojácích, ale nevím, jestli je to dobrý nápad, protože netuším, jak to uvnitř funguje. Co bych měl asi zmínit, že jedu na Lennym (Debian).
Přikládám konfiguráky /etc/multipath.conf a /etc/iscsi/iscsid.conf
Řešení dotazu:
Tak problém částečně odhalen - při zápisu mnoha malých souborů reaguje multipath na odpojení síťovky rychle. Problém tedy bude pravděpodobně v nějakém bufferu...
Po dlouhé době jsem rozhodl podělit se o řešení. Vždycky jsem dostal storage do stavu, že nějakou dobu fungoval, ale třeba po třech týdnech došlo k nepříjemnému zpanikaření kernelu na obou strojích, které k úložišti přistupují. Po velmi dlouhém bádání a doslova pokusech jsem se rozhodl znovu obrátit na podporu Dellu, která mne ale odpálkovala, že nepoužívám podporovaný systém. Nakonec jsem zkusil nasadit CentOS a rázem se situace zlepšila. I/O chyby se objevují sice stejně, ale je jich podstatně méně. Pády systémů naprosto vymizely.
Jaké z toho plyne ponaučení? Dell pro open source Linux nebrat!
S Xenem jsem nikdy nepracoval. Dell se žene zejména za ziskem, o nějaké větší podpoře nemůže být řeč. Jednou jsem v noci volal na jejich hotline a přepojilo mne to na nějaký mezinárodní helpdesk odkud mi nebyli schopni poradit. Na druhou stranu jejich HW servis funguje velmi dobře.
K rychlosti můžu říct jen toto - mám to připojené přes všechny čtyři síťovky ke dvěma serverům. I při minimálním vytížení z toho jen s obtížemi dostanu více jak 80MB/s z jednoho stroje. Údajně je to tak úmyslně. Pokud nastavíte multipath do nějakého load balanced režimu (který mimochodem toto úložiště nepodporuje), dají se z toho dostat chvílemi slušné rychlosti, ale s tím také spousta chyb.
Dost jsem se s tím natrápil a dnes už bych sáhnul po jiném výrobci nebo ještě lépe po nějaké skládačce (třeba Supermicro), kde budu mít vždycky možnost nastavit si systém přesně podle mých potřeb. Nemám rád neprůhledná řešení. Jen pro zajímavost v tomto úložišti tepe Windows (pravděpodobně Windows Embeded)... Navíc už dvakrát se mi stalo, že jeden z management portů přestal fungovat, dokud jsem úložiště natvrdo nevypnul a znova zapnul.
Pokud se chcete pobavit více, napište mi na email nebo jabber, který naleznete v mém profilu.
Zapojeni mame pres switch do POOLu xenserveru, ktery ridi 3X pripojeni do toho iscsi pres 2GBps (sitovky na xenu jsou v bondu ...)
Pokud máte navázány řekněme dvě iSCSI relace, každou přes jinou síťovku, tak jste možná omezen kapacitou jednotlivé síťovky. Pokud chcete ze dvou síťovek vytáhnout dvojnásobek, musel byste nějak zařídit balancing mezi relacemi. Zároveň záleží na tom, jakým provozem testujete průchodnost. Při sekvenčním čtení jediným vláknem se sice Linux snaží o nějaký read-ahead, ale v podstatě se neuplatní TCQ, takže nelze "nafrontovat požadavky do obou iSCSI relací paralelně" - prostě protože se těch požadavků nesejde dostatek. Při čtení více vlákny se paralelní frontování do více iSCSI relací použít dá - ale pokud si nedáte pečlivě záležet, tak zas budou paralelní relace číst každá z jiného místa disku, tzn. disky budou muset seekovat, což může průchodnost dramaticky srazit. Kolik disků je v tom RAIDu a jakých? Kromě toho, pokud si správně pamatuju z mého jediného historického pokusu o load balancing přes dm-mpath, balancing mezi SCSI cestami funguje v režimu "round robin", kdy se vždycky do jedné cesty pošle dávka N požadavků, pak se přepne na alternativní cestu, a zase N požadavků. Hodnotu N lze konfigurovat, ale doporučená hodnota je v každém případě výrazně vyšší než 1, aby se round-robin algoritmus nemusel volat pro každý požadavek extra (kvůli zátěži CPU). Potažmo se dvěma čtoucími vlákny se load balancing taky moc neuplatní Domnívám se, že by to šlo otestovat sekvenčním *zápisem*. Při něm se uplatní write-back, takže VM/IO vrstvy vygenerují z jednoho zapisujícího vlákna sérii požadavků na IO. Pokud budou rozumně nastavené hloubky front (detaily z hlavy nedám) tak by mělo docházet k rozkládání mezi obě linky / SCSI cesty. Pokud testujete zápisem a máte v serveru hodně RAMky, musíte zapisovat mnohem větší soubor, než je velikost RAM, a po spuštění testu chvíli počkat, než se ustálí tok dat (než se buffery v RAMce zaplní po strop) - alternativně lze použít "direct IO", pokud ho lze při zvoleném způsobu generování zátěže nastavit (a nejsem si jist, jestli náhodou zároveň nevykostíte TCQ na úrovni operačního systému). Dále pokud nechcete testovat schopnost disků seekovat, doporučuji zapisovat nikoli skrz filesystém, ale přímo DDčkem apod. sekvenčně na blokové zařízení.
A propos, průchodnost iSCSI: jaké používáte MTU?
Jinak už jsem taky zaslechl, že některé "lepší" storage záměrně omezují průchodnost "per host" (nebo snad per flow, nebo per co vlastně) na nějakých 100 MBps - na rozhraní FC 4Gb. Pokud Vám tohle nevyhovuje, tak zlatá Areca. Já vím - je to jako srovnávat limuzínu s Trabantem...
To je dlouhe Ale pekne
1. To ohledne MSI zni zajimave, ale v tomhle se neorientuji, takze muzu maximalne vyzkouset nejakou tu propustnost a to je vse ...
2.jj ty reakce se daji zmenit, jak temy timeauty , tak primo nastavenim multipatch (pristupove body a zpusob samotenho propojeni) ja mam napriklad round-robin:
root@xenserver ~]# multipath -ll -v2 36a4badb0004ee06f0000039a4c10a9fedm-6 DELL,MD3000i [size=1000G][features=0][hwhandler=1 rdac] \_ round-robin 0 [prio=200][active] \_ 34:0:0:0 sdg 8:96 [active][ready] \_ 33:0:0:0 sdd 8:48 [active][ready]dale jsem vygoogloval, ze ty chyby od toho kernelu jsou vycemene v poradku, ze je to dano treba u toho dell trosku jinym nastanevim toho hwhandleru a rdac, citrix na to ma primo specialni utilitu, co nastavi jadro (initrd) a pak samotne moduly, specialne pro ten dell - zatim jsem neresil ... 3. Pruchodnost je asi OK. ja to mam zapojene "trosku blbe" mam na xenech bond (round-robin) co na SW iSCSCI (slackware + bond) na SAS pole dava cca 100-120 MB/s, vzdy ale obe sitovky pripojeny pres jeden switch (3com) na DELU jsou SATA a docetl jsem se, ze PRIMO ten DELL, pokud ma SAS chova se uplne jinak
Vetsinou testuju, ze kopiruju 20 GB SQL backup ... no a ten samotny dell dava prave "jen" tech 80MB/s sakra ten nemuzu najit tu diskusi .... tak aspon tohle
4. RAID10 + SATA disky (bohuzel). MTU. Default takze 1500, pole umi samozrejme jumbo frames, xenserver taky ... Ale nezjistil jsem, zda switch ano ...
end_request: I/O error, dev sdc, sector 0 end_request: I/O error, dev sdf, sector 0 end_request: I/O error, dev sdc, sector 0 end_request: I/O error, dev sdf, sector 0Ovsem tyto hlasky chodi jen, kdyz: vytvaris novy virtualni disk, hybas s vitrualnim ulozistem jako celkem, kopirujes image a tak .. Pri chodu vitrualniho stroje to nedela ... Pro me je vysledek, ze to neresim, necham to zit takto .. Uvidim, co prinese xenserver 5.6 (ten nasadim az casem ..)
Když hrábnu do archivu, tak jsem tehdy ten multipath nastavoval takhle:
echo "0 2929686528 multipath 0 0 1 1 round-robin 0 2 1 8:0 20 8:16 20" | dmsetup create dma
Tušímže čísla "20" znamenaly délku dávky.
V podstatě je to úleva, že si s těmito hračkami nemusím hrát
Oni i Arecy se SAS portama dávají menší průchodnost na SATA disky než na SAS disky - se SATA diskama jsou v sekvenční průchodnosti asi o čtvrtinu slabší (řekněme 800 MBps vs 600 MBps). Ale občas čtu o konkrétních modelech RAIDových kastlí, které obsahují SASový expandér, že to s konkrétními modely SATA disků buď nefunguje vůbec, nebo třeba že to pro SAS provoz neumí využít multilane SAS link mezi HBA a expandérem, takže to jede jediným 300MBps lanem...
Ohledně MSI: http://www.fccps.cz/download/adv/frr/MSI/PCIe-MSI.html = otravně dlouhé teoretické čtení, rozumné řešení problému s tuhnoucím HBA z toho stejnak neplyne.
Uz davno, pamatujes
Vyzkoušejte a uvidíte.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
5.5.2009 21:48