abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 22:33 | Nová verze

    Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.

    Ladislav Hagara | Komentářů: 0
    včera 17:44 | Zajímavý článek

    Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.

    karkar | Komentářů: 0
    včera 12:11 | Humor

    Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).

    Ladislav Hagara | Komentářů: 2
    včera 10:44 | IT novinky

    Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.

    Ladislav Hagara | Komentářů: 22
    včera 09:55 | IT novinky

    Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.

    Ladislav Hagara | Komentářů: 2
    včera 09:33 | IT novinky

    Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.

    Ladislav Hagara | Komentářů: 0
    včera 08:11 | Nová verze

    Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.

    Ladislav Hagara | Komentářů: 0
    29.4. 20:55 | Nová verze

    Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.

    Ladislav Hagara | Komentářů: 0
    29.4. 16:22 | Nová verze

    Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.

    Ladislav Hagara | Komentářů: 0
    29.4. 15:55 | Pozvánky

    Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových

    … více »
    Zdenek H. | Komentářů: 2
    Jaký filesystém primárně používáte?
     (58%)
     (1%)
     (9%)
     (21%)
     (4%)
     (1%)
     (2%)
     (0%)
     (1%)
     (3%)
    Celkem 494 hlasů
     Komentářů: 19, poslední včera 11:32
    Rozcestník

    Jaderné noviny - 3. 3. 2016: Perzistentní paměť a příznak „vím, co dělám“

    12. 3. 2016 | Redakce | Jaderné noviny | 4489×

    Stav vydání jádra. Zpráva ze soudního slyšení VMware. Perzistentní paměť a příznak „vím, co dělám.“

    Stav vydání jádra

    Současný vývojový kernel nese označení 4.5-rc6 a byl vydán 28. února. Linus k tomu řekl: „Rád bych řekl, že vše směřuje k běžnému datu vydání, ale uvidíme, jak to bude vypadat příští týden. Pokud se rc7 nezačne zmenšovat, možná se rozhodnu, že toto bude vydání, kdy uděláme ještě rc8. Zatím je příliš brzy. Nic strašidelného se neděje, ale byl bych rád za klidnější týden.“

    Stabilní aktualizace: 4.4.3, 3.14.62 a 3.10.98 byly vydány 26. února.

    Verze 4.4.4 (342 změn), 3.14.63 (130 změn) a 3.10.99 (80 změn) byly v době psaní tohoto článku v procesu revidování, nyní již by měly být venku. Díky těmto verzím jádra se fronta aktualizací, čekajících na své zařazení do stabilního jádra, konečně vyprázdnila, říká Greg Kroah-Hartman.

    Welte: Zpráva ze soudního slyšení VMware GPL

    Harald Welte má na svém blogu report ze soudního slyšení v Německu, které se týkalo VMware a jejich údajného porušování GPL. Welte je bývalý jaderný vývojář a také zakladatel gpl-violations.org, takže má o případ velký zájem. Ten vyvolal Christoph Hellwig a platí ho Software Freedom Conservancy. Podle Welteho zde jde o dvě věci: zda jsou vmklinux a vmkernel jedna nebo dvě díla (ve smyslu ochrany práv – copyrightu) a zda má Hellwig právo žalovat: „Situaci využívá VMware k obhajobě tvrzením, že vlastně využili jen velmi málo funkcí, jejichž autorství lze připsat Christophovi, a že celkově může jít o 1 % procento linuxového kódu, který používají v ESXi. Soud uznává složitost případu, protože v německém autorském právu funguje něco, čemu se říká koncept ‚slábnutí‘ (fading). Jestliže došlo k takové úpravě původního díla jednoho autora, že je téměř nerozeznatelné, jeho původní dílo ‚zesláblo‘ a s ním i jeho práva. Soud zatím nerozhodl, zda věří, že se tak stalo. Naopak uvádí, že i několik řádků kódu může mít velký vliv na dílo jako celek. Nicméně je velmi problematické rozhodnout, jelikož soud nerozumí zdrojovým kódům a vývoji softwaru. Takže pokud (po dalších rozpravách z obou stran a projednání u soudu) se bude i nadále jednat o otevřenou věc, může se stát, že si soud vyžádá odborného znalce, který by soudu tyto věci objasnil.“

    Perzistentní paměť a příznak „vím, co dělám“

    Neil Brown minulý týden napsal ve svém článku, že vývojáři pracující na perzistentní paměti mají našlápnuto k vyřešení problému se systémovým voláním fsync(). Funkční fsync() umožní aplikacím ujistit se, že zapsaná data jsou bezpečně uložena v perzistentní paměti – a co je důležitější – že aplikace, které byly korektně napsány pro posixové souborové systémy obecně, budou s perzistentní pamětí fungovat správně, aniž by si všimly rozdílu. Někteří vývojáři ovšem chtějí psát kód, který bude specifický pro perzistentní paměť – jako způsob, jak zvýšit výkon. Patch, který se týká těchto potřeb, se stal předmětem dlouhých debat o tom, jak zajistit, aby se data zapsaná do perzistentní paměti neztratila, a jak by měl vývoj v této oblasti pokračovat.

    Problém se vznikajícím řešením v podobě fsync() je podle Boaze Harroshe v tom, že vyžaduje, aby jádro udržovalo radixový strom všech stránek, které by mohly obsahovat nepřesné nebo nekompletní řádky dat v cache CPU. Jestliže byla aplikace napsána s ohledem na perzistentní paměť, může zabránit v ponechávání dat v cache. Tato data mohou být explicitně přesunuta (flushed) aplikací nebo, jako alternativa, mohou být použito trvalé (non-temporal) zápisování k úplnému obejití cache CPU. Pokud aplikace takové techniky využívá, není podle Boaze potřeba, aby kernel příslušné řádky cache perzistentní paměti mazal, takže je možné zcela se vyhnout plýtvání udržováním radixového stromu.

    Jenže kernel v současné době nemá možnost zjistit, zda se aplikace stará o svou vlastní cache (vyrovnávací paměť). Napravit by to měl Boazův patchset zveřejněný v únoru. Přidává příznak MAP_PMEM_AWARE pro systémové volání mmap(). Pokud aplikace mapuje soubor uložený v perzistentní paměti s tímto příznakem a souborový systém podporuje mechanismus DAX (direct-access), pak může kernel předpokládat, že si aplikace obstará vlastní správu cache a kernel tak nebude muset sledovat stránky s možnými nekompletními řádky cache. Podle Boaze má tento patch velký vliv na zlepšení výkonu.

    Nějaké obavy

    Upřímně řečeno, tento patch se nesetkal s všeobecným přijetím. Objevila se řada námitek, které přidání takové funkcionality kritizují. Zaprvé, i aplikace, která si obstará vlastní cache management, bude muset volat fsync() (potažmo msync()), aby se ujistila, že její data jsou skutečně perzistentní. Děje se tak proto, že data nejsou samostatná – jsou uložená v souborovém systému a aplikace nemůže vědět, zda neexistují nějaká metadata souborového systému, která je třeba přesunout pro zajištění přístupu k datům. Jediným způsobem, jak se přesvědčit, že metadata jsou na disku konzistentní, je volání fsync(), které volají také aplikace, jež pracují s daty na tradičních paměťových médiích.

    Teoreticky může aplikace alokovat a zapsat celý soubor, potom zavolat fsync() pro přesun do perzistentní paměti s cílem, že bude moci posléze přepsat data v souboru bez dalších změn v metadatech (kromě časových razítek, která nejsou pro přístup k těmto datům podstatná). Souborové systémy ovšem mohou provádět akce jako je deduplikace dat, opožděná alokace nebo, jak zmínil Christoph Hellwig, copy-on-write operace. Takže vskutku jediný způsob, jak se ujistit, že jsou data skutečně bezpečně zapsána v perzistentní paměti, je zavolat fsync(). Příznak MAP_PMEM_AWARE by tento požadavek neodstranil.

    Boaz se ohradil tvrzením, že eliminace volání fsync() nebyla nikdy smyslem patche. Místo toho si klade za cíl uskutečňovat tato volání rychleji. Další režie, spojená zejména s výpadky stránek v oblastech nad perzistentní pamětí, by byla snížena. Bohužel, obavy z MAP_PMEM_AWARE tímto nekončí.

    Uvažme například interakci mezi aplikacemi, které využívají tento příznak, a ostatními, které si perzistentní paměti nejsou vědomy. Takové aplikace (a může jít o něco tak jednoduchého jako mv nebo nástroj pro zálohování) mohou vytvářet změny v metadatech, které vyžadují zápis, a mohou tak vytvořit nekompletní řádky cache v oblasti perzistentní paměti, o které aplikace pracující s perzistentní pamětí nic nevědí. Zkušenosti s přímým I/O ukazují, že takové interakce mohou být záludné, těžko detekovatelné a je nemožné je opravit.

    Snad největší starostí jsou vývojáři aplikací, kteří co nejrychleji prohlásí, že jejich kód si je „vědom“ [perzistentní paměti], aniž by ve skutečnosti pochopili vše, co potřebují k tomu, aby se mohli zaručit za integritu svých dat. Podle Dava Chinnera se téměř každý vývojář aplikací, který tvrdí, že rozumí tomu, jak souborové systémy poskytují integritu dat, skoro vždycky plete. Pokud by kernel poskytoval těmto vývojářům příznak „vím, co dělám“, potom by na základě těchto úvah mohli brzy začít psát kód, který dokazuje nedostatek těchto znalostí – na úkor uživatelů.

    Dalo by se říct, že všechny takové aplikace, které obsahují chyby, budou buď opraveny, nebo nahrazeny něčím lepším. Ovšem Dave dal jasně najevo, že takový vývoj nepředvídá.

    Historie nám říká něco jiného. Uživatelé vždy viní nejprve souborový systém, načež vývojáři odmítnou opravit své aplikace, protože si myslí, že by je to buď zpomalilo, nebo se jedná o problém souborového systému, jelikož testovali na jiném souborovém systému a tam to fungovalo. Výsledkem je, že nám nezbude než pracovat s takovými problémy v souborovém systému, aby uživatelé nepřišli o data vlivem mizerných aplikací.

    To stejné se stane zde – souborové systémy budou ignorovat tento speciální příznak „vím, co dělám“, protože drtivá většina vývojářů aplikací ani neví dost na to, aby si uvědomili, že neví, co vlastně dělají.

    Poslední bod je ovšem klíčový. Vývojáři souborových systémů budou z pudu sebezáchovy tento příznak ignorovat, protože alternativou je čelit hněvu uživatelů, kteří je budou vinit ze ztráty dat. Konflikt týkající se ztráty dat na ext4 z roku 2009 zanechal rány, které se dosud nestačily zahojit, a vývojáři si rozhodně nepřejí být znovu v podobné situaci.

    Integrita dat na prvním místě

    Vývojáři měli ještě jeden důvod, proč se stavět proti tomuto patchi – ten však se specifiky patche samotného skoro nesouvisí. DAX a jeho přidružené funkce perzistentní paměti jsou stále nové, takže je jasné, že se stále objevují problémy. Dave prohlásil, že základní problém bezpečného ukládání dat skrze DAX se ještě nepodařilo vyřešit, takže není dobrý nápad zabývat se optimalizacemi. Zatím je třeba soustředit se na spolehlivost. Až pak přijde čas podívat se na problémy s výkonem a optimalizovat.

    Selhání při řešení problémů se správným chováním jen povede k dalším problémům s přibývajícími dalšími funkcemi. Přirovnal to k problému s Btrfs, u nějž se známé problémy nevyřešily včas a výsledkem jsou hluboce zakořeněné nedostatky, které je téměř nemožné odstranit. Pokud se tyto známé problémy nepodaří odstranit dříve v DAXu, může dojít ke stejné situaci.

    Také by rád viděl obecné optimalizace, namísto optimalizace zaměřené na několik málo programů. Oprava problémů místo jejich obcházení přinese výhody všem, tedy lepší výsledek než v případě, že se povolí několika aplikacím implementovat jejich vlastní řešení. Pokud se tyto aplikace rozhodnout dělat si věci po svém, nebudou mít prospěch z těch obecných vylepšení a následně budou mít tato zlepšení menší šanci na realizaci.

    Oddalování a zpožďování prací, které by vývojáři kernelu rádi viděli začleněné, není nikdy příjemné. Daná práce byla vykonána z nějakého důvodu a její odmítnutí znamená, že alespoň nějaká část byla provedena zbytečně, což může vést ke vzniku pocitu křivdy. Ovšem zkušenosti ukazují, že oddalování prací, které působí nehotově nebo v nesouladu s dlouhodobými cíli, vede k lépe udržitelnému jádru v dlouhodobém horizontu. Infrastruktura DAX bude muset dlouho sloužit jako důležitý, jádrem podporovaný přístup k perzistentní paměti. Komunita si nemůže dovolit udělat v tomto případě chybu. Konzervativní přístup je tedy v této oblasti alespoň zatím na místě.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    25.3.2016 11:00 lertimir | skóre: 64 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Jaderné noviny - 3. 3. 2016: Perzistentní paměť a příznak „vím, co dělám“

    Máte někdo vědomosti o jakých problémech s btrfs vlastně mluví v:

    Selhání při řešení problémů se správným chováním jen povede k dalším problémům s přibývajícími dalšími funkcemi. Přirovnal to k problému s Btrfs, u nějž se známé problémy nevyřešily včas a výsledkem jsou hluboce zakořeněné nedostatky, které je téměř nemožné odstranit.

    Na původním článku jsem si našel, že se jedná o:

    ENOSPC, single tree lock, using generic RAID and device layers, etc

    Ale blíže o tom nic nevím, co jsou to za problémy a jaké omezení generují.

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.