Apple představil nový MacBook Pro s čipy M4, M4 Pro a M4 Max.
Na GOG.com běží Halloween Sale 2024. Při té příležitosti lze získat zdarma počítačovou hru Return of the Phantom.
Společnost OpenAI spustila internetový vyhledávač ChatGPT search.
Konference OpenAlt 2024 proběhne již tento víkend 2. a 3. listopadu v prostorách FIT VUT v Brně. Začíná ale už v pátek na warm-up party ve Studentském klubu u Kachničky v 17:00. Pokud jste ještě areál FITu nenavštívili, k dispozici jsou pokyny k orientaci. Na programu je 54 přednášek a workshopů. Témata jsou od silně technických témat jako je třeba GCC nebo PostgreSQL po méně technické témata jako eGovernment, nebo třeba detailní analýzu … více »
Byla vydána nová verze 6.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 14.0.1. Tor client na verzi 0.4.8.13. Thunderbird na verzi 115.16.0.
Vývojáři free a open source synchronizačního nástroje (a p2p náhrady Dropboxu) Syncthing oznámili, že z důvodu odporu ze strany Google Play ukončují podporu OS Android. Bohužel v rámci toho zmizí i vydání Syncthing na F-Droid, který má slabší uživatelskou základnu. Syncthing je na Androidu implementován formou wrapper aplikace, která spustí Syncthing démon, vyžádá potřebná oprávnění a zpřístupní webové rozhraní démona. Ve srovnání se
… více »V červnu 2022 bylo oznámeno, že z K-9 Mailu se stane Thunderbird pro Android. Trvalo to poněkud déle, než vývojáři předpokládali, ale včera byl první stabilní Thunderbird pro Android 8.0 vydán.
Projekt microDMG Racer na Kickstarteru nevyšel, tak se autor rozhodl uvolnit na ESP32 postavené autíčko i ovladač jako open source.
Byl vydán TrueNAS SCALE 24.10 „Electric Eel“. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Byla vydána nová verze 24.10.29 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nově s podporou AI (whisper.cpp) pro generování titulků. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Aktuální vývojová verze jádra je 3.3-rc1 vydaná 19. ledna; začleňovací okno 3.3 je nyní uzavřené. Tak či tak je to vydané a já předčasně odjíždím na víkend plný piva, lyžování a pokeru (nemusí to být v tomto pořadí: 'před lyžováním nepij'). Nebudu na mailu. Přečtěte si shrnutí začleňovacích oken (část první a druhá), abyste se o novinkách zařazených do verze 3.3 dozvěděli více.
Teď se trochu vzdaluji od tématu, ale binární ovladače nvidia jsou tím nejlepším způsobem, jak můžeme uživatelům dodat funkce odpovídající tomu, co je dostupné na jiných operačních systémech. Z technických důvodů jsme se rozhodli využívat spoustu společného interně napsaného kódu, což nám umožňuje podporovat nové hardwarové a softwarové funkce mnohem rychleji, než kdybychom to my, co pracujeme na ovladačích pro Linux/FreeBSD/Solaris, museli psát od píky. To znamená, že máme mnoho společného s ostatními ovladači NVIDIA, ale také to znamená, že nemůžeme infrastrukturu moc sdílet jako DRI.
U všech jader obsahujících můj kód je tento kód pod GNU Public License v2 (v některých případech 'nebo novější'), nikdy jsem neudělil souhlas, aby tento kód byl používán jako součást kombinovaného nebo odvozeného díla, které obsahuje binární části. Nikdy jsem neřekl, že modulů se GPL nějakým zázračným způsobem netýká, a mám pochyby, že jsou díla obsahující binární moduly ve shodě s licencí, ačkoliv uznávám, že v některých případech to tak být může.
-- Alan Cox
Linux má řadu souborových systémů, ale dvěma z nich (ext4 a btrfs) je věnováno nejvíce pozornosti. Ve své přednášce na linux.conf.au 2012 vývojář XFS Dave Chrinner poznamenal, že si myslí, že by lidé měli více zvažovat XFS. Během své řeči mluvil o práci, kterou odvedli, aby se vyřešily největší problémy se škálováním v XFS, a také o tom, kam si myslí, že vývoj bude dále směřovat.
XFS je často považováno za souborový systém pro lidi pracující s obrovskými objemy dat. Dave řekl, že XFS tuto funkci zastává dobře a tradičně si v mnoha situacích vede dobře. Horší to už ale bylo se zápisem metadat; podpora pro nasazení, kde se vytváří hodně metadat, byla dlouhotrvajícím slabým místem tohoto souborového systému. Ve zkratce se dá říct, že zápisy metadat byly pomalé a neškálovaly dobře dokonce ani se dvěma CPU.
Jak moc pomalé to bylo? Dave ukázal několik slajdů s výsledky ve fs-marku ve srovnání s ext4. XFS bylo znatelně horší (klidně o polovinu pomalejší) i na jediném CPU; situace se ještě zhoršila při osmi vláknech, kdy člověk s ext4 narazí a začne se také zpomalovat. Dave řekl, že při zátěžích s velkým objemem změn v metadatech – například při rozbalování tarballu – může být ext4 20 - 50krát rychlejší než XFS. To je dost pomalé na to, aby to poukazovalo na problém.
Tím problémem se ukázalo být žurnálové I/O; XFS generovalo obrovské objemy dat do žurnálu v reakci na změny v metadatech. V nejhorších případech téměř všechno I/O bylo kvůli žurnálu – nikoliv kvůli skutečně zapisovaným datům. Řešení tohoto problému během uplynulých let vedlo k několika různým pokusům, jedné velké změně v algoritmu a řadě dalších významných optimalizací a dalším „poladěním“. Jednou z věcí, které nebylo potřeba udělat, je změna formátu dat na disku – ačkoliv na tom se možná bude v budoucnu dělat z jiných důvodů.
Zátěže s velkým dopadem na metadata mohou během chvilky mnohokrát měnit stejný blok adresáře; každá z těchto změn vytváří záznam, který musí jít do žurnálu. Toto je v žurnálu zdrojem obrovského provozu. Řešení problému je ve své podstatě jednoduché: opozdit aktualizace žurnálu a kombinovat bloky do jediné položky. Samotná implementace tohoto nápadu, aby to bylo škálovatelné, dala během posledních let dost zabrat, ale teď už to funguje; opožděné logování bude jediným podporovaným režimem žurnálu v jádře 3.3.
Samotná technika opožděného logování byla ukradena převážně ze souborového systému ext3. Protože se už ví, že algoritmus funguje, netrvalo tak dlouho dokázat, že to zabere i u XFS. Kromě výkonnostních výhod tato změna vedla ke zmenšení celkového objemu kódu. Ti, které zajímá, jak to funguje, se mohou dozvědět ještě více, než původně chtěli, v jaderné dokumentaci.
Opožděné logování je velká změna, ale zdaleka ne jediná. Rychlá cesta [fast path] rezervace místa v logu je v XFS dosti zatěžovaná; nyní se obejde bez zámku, ačkoliv pomalá cesta stále vyžaduje globální zámek. Asynchronní zpětný zápis metadat vytvářel dosti nesouvislé I/O, což velmi omezovalo výkon. Nyní je zpětný zápis metadat před samotným zápisem opožděn a data jsou seřazena. To podle Davových slov znamená, že souborový systém odvádí práci za plánovač I/O. Jenomže plánovač I/O pracuje s frontou, která je obvykle omezena na 128 položek, zatímco opožděný zpětný zápis metadat XFS může mít tisíce položek, takže má smysl je řadit ještě před předáním. „Aktivní položky logu“ jsou mechanismem, který zlepšuje výkon (velkého) seřazeného seznamu položek hromaděním těchto změn a jejich zařazováním po skupinách. Cachování metadat bylo dále přesunuto z cache stránek, které mělo tendenci vyřazovat stránky v nevhodnou dobu. A tak dále.
Tak jak XFS škáluje teď? S jedním nebo dvěma vlákny je lehce pomalejší než ext4, ale do osmi vláken škáluje lineárně, zatímco ext4 se zpomaluje a btrfs se zpomaluje ještě víc. XFS nyní ve škálování omezuje zamykání na úrovni VFS, už ne kód XFS samotného. Procházení adresářů je nyní rychlejší i s jedním vláknem a s osmi ještě rychlejší. Dodal, že toto nejsou výsledky, kterými by se lidem mohli pochlubit vývojáři btrfs.
Škálovatelnost alokace místa je nyní „řádově“ rychlejší než u ext4. To se s funkcí „bigalloc“ přidanou ve verzi 3.2 trochu mění, protože ta zlepšuje alokaci místa v ext4 o dva řády, pokud je použita dostatečná velikost bloků. Bohužel také o stejný objem zvětšuje objem místa zabraný malými soubory, takže pak strom jádra zabírá klidně 160 GB. Bigalloc nefunguje dobře spolu s dalšími volbami ext4 a od administrátora se vyžaduje hlubší přemýšlení nad budoucností, zejména pak, jak bude souborový systém během svého života používán. Dave řekl, že ext4 trpí nedostatky v architektuře – zejména pak používáním bitmap pro sledování volného místa – které jsou typické pro souborové systémy z 80. let. Je nemožné, aby toto škálovalo na skutečně velké souborové systémy.
Alokace místa v Btrfs je oproti ext4 dokonce ještě pomalejší. Dave řekl, že problém spočívá zejména v procházení cache volného místa, což je aktuálně náročné na CPU. Toto není v případě btrfs problém architektury, takže by to mělo jít vyřešit, ale vyžádá si to práci na optimalizacích.
Kam budeme směřovat dál? V současnosti lze výkon a škálovatelnost metadat na XFS považovat za vyřešený problém. Úzké hrdlo teď představuje vrstva VFS, takže další vlna práce musí být odvedena tam. Velkou výzvou budoucnosti ale zůstává spolehlivost; ta si může v XFS vyžádat velké změny.
Spolehlivost není jen věcí neztrácení dat – to XFS už snad umí – jde spíše o věc škálovatelnosti. Jednoduše není moc praktické odpojit systém o velikosti v řádu petabajtů a spouštět nástroje pro kontrolu a opravu souborového systému; toto se bude muset provádět za provozu. To si vyžádá robustní detekci chyb přímo v souborovém systému, aby bylo možné metadata opravovat za běhu. Některé jiné souborové systémy už validaci dat implementují také, ale to je považováno za věc mimo oblast XFS; validaci dat je podle Davea lepší dělat na úrovni diskových polí nebo aplikace.
"Validací metadat" se myslí to, že metadata budou samopopisná, aby byl souborový systém ochráněn proti zápisům, které úložiště udělalo jinam, než mělo. Přidání kontrolních součtů nestačí – kontrolní součet jen zaručuje, že bylo zapsáno to, co být zapsáno mělo. Důkladně popsaná metadata mohou vést k odhalení bloků, které byly zapsány na nesprávná místa, a pomoci při obnově závažně poškozeného souborového systému. Mohou tak pomoci i proti „problému reiserfs“, kdy je nástroj pro opravu souborového systému zmaten starými metadaty nebo metadaty uloženými v obrazech souborových systémů uložených na souborovém systému, který je opravován.
Předělání metadat na samopopisná si vyžádá spoustu změn. Každý blok metadat bude obsahovat UUID souborového systému, do kterého patří; v každém bloku pak budou čísla bloků a inodů, aby souborový systém mohl ověřit, že metadata pocházejí z očekávaného místa. K odhalení poškozených dat budou sloužit kontrolní součty a identifikátor vlastníka, aby metadata byla přiřazena k nadřazenému inode nebo adresáři. Alokační strom se zpětným mapováním umožní souborovému systému rychle odhalit, kterému souboru jakýkoliv blok patří.
Není snad ani třeba říkat, že současný diskový formát dat XFS pro tato dodatečná data nemá místo. To znamená změnu formátu dat. V plánu podle Davea není přijít s jakoukoliv dopřednou nebo zpětnou kompatibilitou; změna formátu bude mít podobu revoluce. Smyslem je mít volnou ruku při návrhu nového formátu, který bude uživatelům XFS sloužit po dlouhou dobu. Ačkoliv je formát měněn jen kvůli přidání výše uvedených vlastností pro zvýšení spolehlivosti, vývojáři přidají do adresářové struktury i místo pro d_type, počítadla verze NFSv4, čas vytvoření inode a pravděpodobně ještě další věci. Maximální velikost adresáře, která je teď jen 32 GB, bude taktéž navýšena.
Toto umožní spoustu pěkných věcí: proaktivní detekci poškození souborového systému, nalezení a nahrazení odpojených bloků a lepší online opravu souborového systému. To podle Davea znamená, že XFS zůstane nejlepším linuxovým souborovým systémem pro velké objemy dat ještě dlouho.
Jaké jsou ale dopady všech těchto věcí z pohledu btrfs? Dave říká, že btrfs jednoznačně není optimalizované pro souborové systémy s velkým provozem v metadatech; v cestě stojí závažné problémy se škálovatelností. U souborového systému v raných fázích vývoje se nelze divit. Některé z těchto problémů budou vyřešeny časem, ale je možné, že některé nepůjde vyřešit. Na druhou stranu jsou funkce pro spolehlivost v btrfs dobře navrženy a btrfs je na tom dobře z hlediska zvládání budoucích velkých úložišť.
Takové ext4 ale trpí problémy se škálovatelností architektury. Podle Davových výsledků už to není nejrychlejší souborový systém. Co do spolehlivosti není mnoho plánů na zlepšení a jeho diskový formát znatelně stárne. Ext4 bude mít problém s podporovou budoucích systémů úložišť.
Dave měl na konci své přednášky otázku. Ext4 bude brzy na pozici výchozího souborového systému na mnoha distribucích nahrazeno btrfs díky jeho funkcím. Mezitím je ext4 překonáváno XFS při většině typů zátěží a to včetně těch, kde ext4 bylo tradičně silnější. Objevují se problémy se škálováním, a to i na malých serverových systémech. Jde o „konglomerát napůl hotových projektů“, které spolu ne vždy dobře fungují; ext4 není podle slov Davea tak stabilní nebo dobře otestované, jak si lidé myslí. Proto se zeptal: na co ext4 stále potřebujeme?
Člověk by předpokládal, že vývojáři ext4 budou na tuto otázku mít neprůstřelnou odpověď, v místnosti ale žádní nebyli. Takže to vypadá, že diskuze bude muset pokračovat někdy jindy; bylo by zajímavé ji pozorovat.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Na druhou stranu jsou funkce pro spolehlivost v btrfs dobře navrženy a btrfs je na tom dobře z hlediska zvládání budoucích velkých úložišť.To tedy jsou. Vizte můj poslední blogpost - Šoupání s daty. Mimochodem ty co jej četli bych rád upozornil na jeho update, kde jsou uvedeny konkrétní časy. Jednoznačně z nich plyne, že nemá smysl dělat mixované pole z disků SATA II a SATA III. Pokud má vaše deska SATA III a chcete si sestavit pole, tak se teď vyplatí investovat pouze do SATA III disků a ty starší pak věnovat někomu, kdo tuto podporu nemá. Tyto jaderné noviny vznívají jako vyložené PR pro XFS a ext4. Což mě nepřekvapuje. Já mám ext4 použité momentálně na systémovém SSD disku a už jsem měl tu čest vidět při výpisu místo práv sérii otazníčků. Takže děkuji, ale na cennější data volím raději experimentální btrfs, u kterého jsem se s něčím podobným za celou dobu co jej používám nesetkal. Bohužel pro obšírnější testy, na jejichž základě by bylo možné na tomto poli otestovat další aspekty různých FS, tak jak jsou zmiňovány výše, na reálných datech, nemám především dostatečný diskový potenciál. Porty by se ještě našly.
reiserfsck
nad 16TB malých souborů? To už je bezpečnější žonglovat pochodněmi na benzínce...
riserfsck
...
btrfs je na tom dobře z hlediska zvládání budoucích velkých úložišťNo jistě. Jen co zlevní disky
Ve tvém případě to chápu tak že máš 6TB pro soukromé použití - co tam prosímtě budeš ukládat???Sbírka porna na 4 roky dopředu v DVD kvalitě?
a mám na něm komplet všechna data za x let nazpět.Takže to péčko?
Ve tvém případě to chápu tak že máš 6TB pro soukromé použití - co tam prosímtě budeš ukládat??? To nemyslím jako prudění, fakt mě to zajímá, protože sám si nedovedu představit že bych v současné době dokázal něco podobného smysluplně využít.
Tak ono to záleží na tom, co kdo na kompu dělá. Mě udivují komentáře jako jsou tyto. Přesto, Alešův zápisek mě vyprovokoval k tomu, abych si alespoň jeden víkend zaznamenal co kolik místa spotřebuje:
Sám mám celkem asi 5TB storage prostoru (na různých kompech, ne v celku) a zaplnit to opravdu není problém. Konkrétní případ z jedný lednový soboty. Přepadla mě můza, vyběhl jsem s foťákem s vidinou udělat nějaká panoramata. Jeden obrázek v TIFF (hugin nebere CR2) má cca 90MB. Za hoďku focení to máš 100 fotek (pro záběry z různých míst), tj nějakých 9GB dat + další místo na zpracování, zkrátka za jednu jedninou "foto seanci" tj cca 15GB dat. Druhej den jsem se pokoušel o cosi v Audacity a adresář s projektem (2h mluveného slova, pokus o podcast) má taky nějakých 10GB. Tj celkem 25GB vlastních dat za jeden víkend...
Opravdu není problém vlastními daty zaplnit xTB pole.
Kdyby se seklali tvůrci všech těchto filesystémů na delší společné debatě na témaNo nevím jestli jsou návštěvní podmínky a hodiny v Pleasant Valley State Prison nějaké takové debatě nakloněné :)