Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
Mnozí z Vás se jistě chtěli seznámit s pojmem souborový systém hlouběji. Ačkoliv si myslím, že se drtivá většina s pojmem souborový systém setkala, přesto ho nejprve objasním. Je to software, který slouží k organizování a používání dat uložených na záznamových médiích (pevný disk, CD apod). Souborový systém zajišťuje integritu dat (přeloženo do českého jazyka ucelenost). Tudíž informace, které uložíme, budeme moci později vyvolat v nezměněné podobě.
Pro svou činnost filesystém ukládá informace o souborech a informace o sobě samotném (vlastnictví, datum, kontrola přístupu, délka souboru a jeho lokace na disku apod). Bez těchto informací, tzv. metadata, by souborový systém nemohl pracovat. Nebudu se tu zabývat souborovými systémy jako ext2fs (běžně používaný souborový systém v OS Linux), o něm byla jistě již spousta materiálu sepsána a tak nebudu nosit dříví do lesa. Navíc nové filesystémy mají lepší vlastnosti a nemají tak přísná omezení jako třeba právě ext2fs.
Modernější filesystémy použijeme zvlášť, pokud chceme zajistit integritu dat i při náhlém přerušení práce počítače. Existuje několik možností, co se při náhlém přerušení práce může stát:
Standardní linuxový souborový systém (ext2fs) svému poškození částečně předchází tím, že udržuje redundantní kopii metadat, takže se většinou nestává, že bychom o ně přišli. Pomocí kontroly integrity souborového systému (fsck), klasicky během bootování, je systém schopen zjistit, kde jsou metadata poškozená a nahradí je prostým zkopírováním redundantní verze. Nebo dojde ke smazání souboru, který byl přerušením poškozen. Samozřejmě že kontrola trvá tím déle, čím větší máme diskový oddíl a kontrola opravdu velkého disku může trvat velmi dlouho. Žádná z uvedených vlastností se samozřejmě nikomu z nás nelíbí, naštěstí existuje alternativa k těmto klasickým druhům filesystémů. Jsou jimi souborové systémy, které pracují s tzv. žurnálem.
O co se jedná. Stručně řečeno žurnálovací filesystém si uchovává informace o operacích, které provedl a je pak v případě výpadku schopen rychle se dostat zpět do konzistentního stavu. Změny jsou evidovány jako tzv. transakce. Jedná se o nezávislé atomické operace. Po každé transakci následuje potvrzení, když dojde k uskutečnění daného úkonu (např. zápis na disk). Proto pokud systém "spadne", můžeme najít v záznamech informace o provedených změnách a vrátit vše do původního stavu. Mezi tyto souborové systémy patří např. ext3, ReiserFS, XFS a JFS. V našem seriálu se postupně zmíníme o každém z nich podrobněji.
Problémy při výpadcích však nejsou zdaleka jedinými nevýhodami tradičních souborových systémů jako ext2fs. Všechny byly navrženy v době, kdy záznamová média neměla takovou kapacitu jako v současné době. Dnes máme větší soubory, adresáře a také diskové oddíly a starší souborové systémy už nestačí ať už z hlediska různých omezení velikostí nebo výkonu. Tyto problémy jsou důsledkem interních struktur, na kterých jsou založeny. Hlavním problém je, že mají pevně danou délkou, což limituje jejich možnosti. Také metody, které v dřívější době vyhovovaly, jsou už při dnešních možnostech z hlediska výkonu nedostačující. Souborové systémy nové generace jsou navrhovány tak, aby problémům omezení předcházely.
V následující tabulce si můžete porovnat omezení jednotlivých souborových systémů:
| Filesystém | Max. velikost filesystému | Velikost bloků | Max. velikost souboru |
| Ext2 | 4 TB | 1KB-4KB | 2 GB |
| Ext3 | 4 TB | 1KB-4KB | 2 GB |
| ReiserFS | 16 TB | až 64KB | 2^10 PB *1 |
| XFS | 18000 PB *1 | 512B - 64KB | 9000 PB *1 |
| JFS | 512 B / 4 PB *2 | 512B, 1024B, 2048B, 4096B | 512B / 512Tb *2 |
*1) 1PB = 10^15 B
*2) Maximální velikost souborového systému závisí na velikosti bloku dat, velikosti pro ostatní hodnoty dostaneme jednoduše pomocí trojčlenky.
Dalším problémem jsou struktury, pomocí kterých souborový systém hledá volné bloky při ukládání dat. Často se jedná o seznam, kde jsou udržována čísla jednotlivých volných bloků. UFS a ext2fs používá bitmapu, což je pole bitů, kde každý z nich odpovídá jednomu logickému bloku na diskovém oddílu. S narůstající kapacitou délka pole narůstá a výkon klesá.
Problémům, týkajících se hledání volných bloků dat, se vyvarujeme použitím tzv. "extents" a balancovaného stromu. Extents je skupina sousedících logických bloků, které jsou používány některými filesystémy. Deskriptor extents obsahuje 3 údaje:
V případě použití extents nezávisí velikost struktury, kde si uchováváme informace o volném místu, na velikosti filesystému. Také použitím balancovaného stromu místo prostého seznamu dochází k dalšímu zvýšení výkonu.
V případě velkého počtu položek adresáře je efektivita u starších souborových systému opět slabší. Často jsou položky adresáře ukládány do seznamu, a tudíž jejich následné vyhledávání je zbytečně zdlouhavé. Jedním z řešení je opět použití balancovaného stromu, kde jsou tyto položky uspořádány podle jmen.
Výkonnost však nedostačuje ani u velkých souborů. Pro vysvětlení této oblasti si musíme neprve objasnit pojem i-node. Jedná se o strukturu, kde souborový systém udržuje informace o souboru, jako jsou práva, typ souboru a hlavně ukazatele na bloky souborového systému, kde je soubor uložený. Obsahuje jednak přímé ukazatele, a také tzv. nepřímé ukazatelé, odkazující na bloky s ukazately přímými. Viz obrázek:
Problém spočívá v navržení struktury i-nody. Starší souborové systémy byly vytvářeny převážně pro práci s menšími soubory. Struktura i-nodů je proto ne zrovna efektivní. Čím větší soubor používáme, tím vícekrát přistupujeme k disku díky nepřímým pointrům. Důvodem, proč nepřímé pointry vůbec ext2fs používá, je to, že i-node má pevnou velikost.
Problém velkých souborů může být odstraněn použitím dynamického alokování i-nodů. Bohužel musíme vyřešit otázky jak zařídit mapování logických bloků i-nodu a jaké použít struktury na vyhledávání v rámci i-nodu. Řešením je většinou použití balancovaných stromů.
Omezení externí fragmentace a podpora řídkých souborů (sparse files) je také jednou z výhod nových filesystémů (ovšem jejich podpora je už v ext2fs). Pojem fragmentace většina čtenářů jistě zná, jen připomenu že se jedná o rozptýlení jednotlivých bloků souboru po disku a hlavička disku pak při čtení musí přejíždět z místa namísto. Samozřejmě výhodnější je mít bloky za sebou, operace pak budou rychlejší.
Řídké soubory jsou soubory, které vzniknou následujícím způsobem:
Zapíšeme například několik počátečních bytů dat a poté se chceme zapsat data uvnitř souboru, která odpovídají offsetu třeba 50000. Pokud nemá náš filesystém podporu pro řídké soubory, alokujeme všechny byty mezi počátkem a těmi bloky uvnitř souboru. Bloky mezi počátkem a offsetem 50000 nás však nezajímají a vůbec by alokovány být nemusely. Pokud použijeme souborové systémy s podporou řídkých souborů, pak se alokuje jen tolik místa, kolik zapisovaná data skutečně zabírají.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
protoze to je zde uvedeno spatne ... wiki tvrdi ze je to zavisle na velikosti bloku:
ext3 has a maximum size for both individual files and the entire filesystem. For the filesystem as a whole that limit is 232 blocks.Block size Max file size Max filesystem size 1 KB 16 GB 2 TB 2 KB 256 GB 8 TB 4 KB 2 TB 16 TB 8 KB[limits 1] 2 TB 32 TB
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
23.6.2010 11:34