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 12:55 | Nová verze

Byla vydána verze 17.12.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi. Aplikace, které nebyly dosud portovány na KDE Frameworks 5, byly z KDE Aplikací odstraněny.

Ladislav Hagara | Komentářů: 20
včera 03:00 | Komunita

Na Humble Bundle lze získat počítačovou hru Company of Heroes 2 (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 0
včera 02:00 | Zajímavý software

Christian Kellner představil na svém blogu projekt Bolt řešící bezpečnost rozhraní Thunderbolt 3 na Linuxu. Pomocí příkazu boltctl nebo rozšíření GNOME Shellu lze komunikovat s démonem boltd a například zakázat neznámá zařízení a předejít tak útokům typu Thunderstrike nebo DMA.

Ladislav Hagara | Komentářů: 6
včera 01:00 | Nová verze

Po půl roce vývoje od vydání verze 11.0 byla vydána verze 11.1 svobodného softwaru pro vytváření datových úložišť na síti FreeNAS (Wikipedie). Nejnovější FreeNAS je postaven na FreeBSD 11.1. Přehled novinek v příspěvku na blogu. Zdůraznit lze zvýšení výkonu OpenZFS, počáteční podporu Dockeru nebo synchronizaci s cloudovými službami Amazon S3 (Simple Storage Services), Backblaze B2 Cloud, Google Cloud a Microsoft Azure

Ladislav Hagara | Komentářů: 0
14.12. 23:55 | Nová verze

Po dvou měsících vývoje od vydání verze 235 oznámil Lennart Poettering vydání verze 236 správce systému a služeb systemd (GitHub, NEWS).

Ladislav Hagara | Komentářů: 6
14.12. 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
14.12. 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
14.12. 18:11 | Nová verze

Byla vydána verze 2.11.0 QEMU (Wikipedie). Přispělo 165 vývojářů. Provedeno bylo více než 2 000 commitů. Přehled úprav a nových vlastností v seznamu změn.

Ladislav Hagara | Komentářů: 0
14.12. 17:44 | Komunita

Canonical oznámil dostupnost kryptografických balíčků s certifikací FIPS 140-2 úrovně 1 pro Ubuntu 16.04 LTS pro předplatitele podpory Ubuntu Advantage Advanced. Certifikace FIPS (Federal Information Processing Standards) jsou vyžadovány (nejenom) vládními institucemi USA.

Ladislav Hagara | Komentářů: 3
14.12. 16:11 | Zajímavý software

Společnost Avast uvolnila zdrojové kódy svého dekompilátoru RetDec (Retargetable Decompiler) založeného na LLVM. Vyzkoušet lze RetDec jako webovou službu nebo plugin pro interaktivní disassembler IDA. Zdrojové kódy RetDec jsou k dispozici na GitHubu pod open source licencí MIT.

Ladislav Hagara | Komentářů: 3
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (76%)
 (14%)
Celkem 997 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje

    10. 6. 2014 | Luboš Doležel | Jaderné noviny | 4121×

    Aktuální verze jádra: 3.15-rc6. Citáty týdne: Frederic Weisbecker, Paul McKenney, Andrew Morton. Tux3 zaslán k revidování. 2038 je blíže, než se zdá.

    Obsah

    Aktuální verze jádra: 3.15-rc6

    link

    Aktuální vývojová verze jádra je 3.15-rc6 vydaná 22. května. Jelikož rc5 vyšlo o pár dní dříve a rc6 o několik dnů později, tak mezi nimi byly skoro dva týdny. Výsledná velikost ale není dvojnásobná, snad i díky tomu, že se blížíme k závěru řady rc a už by se to mělo uklidňovat, ale možná i proto, že někteří správci neposlali své žádosti o přetažení, protože věděli, že jsem offline. Ať už je to jakkoliv, nevypadá to špatně. Linus se u rc7 plánuje vrátit k obvyklému nedělnímu vydávání, tedy snad 1. června, a mělo by jít o snad poslední rc v řadě 3.15.

    Stabilní vydání: verze 3.4.91 vyšla 18. května s řadou důležitých oprav, včetně jedné (známé) důležité bezpečnostné opravy. Ti, kdo mají rádi své jádro obzvlášť stabilní, se mohou uchýlit k verzi 2.6.32.62 vydané 21. května; zahrnuje opravy 39 chyb s číslem CVE.

    Citáty týdne: Frederic Weisbecker, Paul McKenney, Andrew Morton

    link

    Už si mě vyhlédli draví zmrzlí žraloci, kteří nade mnou létali v kruzích po mých několika nedávných přeinženýrovaných vizích.

    -- Frederic Weisbecker

    Vzhledem k tomu, že jsem neslyšel příliš mnoho stížností na přílišnou jednoduchost RCU, bych se rád vyhnul změnám v masce nohz_full za běhu.

    -- Paul McKenney

    Vkládání věcí okolo MM do kódu čekajících front je poněkud špatné. Opravdu nevím, jak tohle vysvětlím své rodině.

    -- Andrew Morton

    Tux3 zaslán k revidování

    link

    Po letech vývoje a několika nepodařených startech byl systém souborů Tux3 zaslán k revidování ve snaze dostat jej v nejbližší budoucnosti do hlavní řady. Tux3 nabízí řadu slibných funkcí patřících do systémů souborů nové generace s vysokou úrovní spolehlivosti. Zaslání patche je pro Tux3 krokem kupředu, ale asi ještě nějakou dobu potrvá, než se dostane do hlavní řady.

    Jediný člověk, který kód zatím kontroloval, byl Dave Chinner a nebyl zrovna nadšený. Musí se toho hodně pročistit, ale Dave má obavy hlavně kvůli různým věcem okolo správy paměti a změnám v systému souborů, které by podle něj měly být odděleny k samostatnému revidování. Jeden z hlavních mechanismů Tux3 nazvaný „forkování stránek“ nebyl na loňském Sumitu o úložištích, systémech souborů a správě paměti přijat moc dobře a vývojář Tux3 Daniel Phillips od té doby ke zlepšení moc nepřispěl.

    Dave má také obavy z nedokončené povahy řady slibovaných funkcí. Před léty bylo Btrfs začleněno v nekompletním stavu a doufalo se, že to urychlí vývoj; Dave nyní říká, že to byla chyba, kterou nechce opakovat:

    Vývoj btrfs ukázal, že přesun prototypů systémů souborů do hlavní řady jádra nevede ke stabilitě, výkonu nebo připravenosti k produkčnímu nasazení rychleji, než když zůstanou mimo jádro, dokud není většina vývoje hotová. Začlenění do hlavní řady naopak omezuje rychlost, jakou se systém souborů může dostat do kompletního stavu a připravenosti k produkčnímu nasazení.

    Suma sumárum to vede k nepříliš vřelému přijetí. Daniel ale chce tento kód dostat do stavu, kdy půjde kód začlenit. Pokud na to dojde, měli bychom vidět řadu menších patchů, které usnadní revidování změn specifických pro Tux3. Teprve až bude tento proces dokončen, bude čas na to uvažovat o začlenění do hlavní řady jádra.

    2038 je blíže, než se zdá

    link

    Většina z čtenářů Jaderných novinek si je dobře vedoma zkázy, která nás čeká v lednu 2038, kdy datovému typu time_t používanému k ukládání časových hodnot (v podobě sekund od 1. ledna 1970) dojdou na 32bitových systémech bity. Může být překvapivé, že si vývojáři dělají čím dál větší obavy z tohoto termínu, když ještě zbývá 24 let, ale jsou pro to dobré důvody. Zdali tyto obavy povedou k brzkému řešení, se ještě uvidí; od srpna minulého roku, kdy se toto téma vynořilo naposledy, se toho moc nestalo. Nedávné debaty ale ukazují, jak by řešení mohlo vypadat.

    Byly doby, kdy vývojáři doufali, že se problém vyřeší sám. Na 64bitových systémech byl typ time_t vždy definován jako 64bitová hodnota a v dohledné době mu místo nedojde. Vzhledem k tomu, že 64bitové systémy asi přebírají vládu nad světem – k přechodu dojde v nejbližších letech i na telefonech – nemohlo by nejlepším řešením být jen počkat, než 32bitové systémy zhynou a spolu s nimi i tento problém? Řešení, kdy se nemusí nic dělat, je samozřejmě lákavé.

    Tento nápad má dva problémy: 1) 32bitové systémy se budou pravděpodobně vyrábět mnohem déle, než by většina lidí čekala a 2) v současnosti se nasazují 32bitové systémy, u kterých se očekává životnost delší než 24 let. 32bitové systémy budou ještě dlouho užitečné jako levné mikrokontroléry a po jejich nasazení se bude často očekávat, že poběží po mnoho let a přitom bude obtížné či nemožné je aktualizovat. Jistě už byly nasazeny systémy, které v roce 2038 budou nepříjemným překvapením.

    Jaderná řešení

    link

    Proto dává smysl řešit problém dřív než, řekněme, v roce 2036. Má to ale háček: problém není tak lehké vyřešit. Alespoň pokud má člověk obavy z drobných detailů jako rozbití stávajících systémů. Protože linuxoví vývojáři na většině úrovní mají obavy o kompatibilitu, nejjednodušší řešení (jako rozbití ABI na BSD) se nepovažují za přijatelná. John Stultz v nedávné debatě naznačil několik alternativních řešení, žádné z nich ale není bez komplikací.

    První přístup spočívá ve změně 32bitového ABI na 64bitovou verzi time_t (změnily by se i související datové struktury jako struct timespec a struct timeval). Staré binárky by byly podporovány přes rozhraní pro kompatibilitu, zatímco nové by normálně používaly nové ABI. Tento přístup má své výhody, například tu, že řada aplikací by šla aktualizovat jednoduše tak, že by se překompilovaly. Vzhledem k tomu, že několik variant BSD už touto cestou šlo, řada nejhorších problémů s aplikacemi již byla vyřešena. Vestavěné mikrokontroléry obvykle běží na vlastních distribucích sestavených kompletně ze zdrojových kódů; změna ABI tímto způsobem by umožnila vytvoření systémů funkčních po roce 2038 už v blízké budoucnosti s minimem obtíží.

    Na druhou stranu by jádro muselo udržovat rozsáhlou vrstvu pro kompatibilitu po dlouhou dobu. Vývojáři mají navíc obavy, že se najde řada aplikací, které ukládají 32bitové hodnoty time_t do vlastních datových struktur, formátů na disku a tak dále. Řada těchto aplikací by se rozbila nečekaným způsobem a bylo by obtížné je opravit. Jsou tu také obavy kvůli režii spojené s používáním 64bitových hodnot time_t na 32bitových systémech. Většině této režie by se dalo předejít v jádře tím, že by se interně používal odlišný formát, ale aplikace by se mohly zpomalit také.

    Alternativou je zkrátka definovat novou sadu systémových volání, která by od počátku používala lepší formáty času. Nové formáty by rovnou mohly vyřešit další nepříjemnosti; ne všichni mají například rádi oddělené pole pro sekundy a nanosekundy ve struct timespec. Všechna systémová volání používající staré hodnoty time_t by byla označena za zastaralá s tím, že by byla odstraněna třeba ještě před rokem 2038.

    Při tomto přístupu by nedošlo v blízké době k žádnému velkému rozbití ABI a aplikace by mohly přecházet postupně. Vestavěné systémy by mohly být zkompilovány s novými systémovými voláními v docela dohledné době, zatímco desktopové systémy by bylo možné nechat třeba ještě deset let být. A byla by to příležitost k opětovnému navržení některých dávných systémových volání s ohledem na potřeby 21. století.

    Zapojení glibc

    link

    Diskuze nad těmito alternativami trvala překvapivě dlouho, než Christoph Hellwig přišel se svým (nyní) zjevným návrhem: vývojáři knihovny C budou muset být v řešení tohoto problému zapojeni, tak by snad mohli být i součástí diskuze. Po celé roky byla komunikace mezi jadernou komunitou a vývojáři knihoven C (včetně GNU knihovny C – glibc) přinejlepším sporadická. Změna vedení glibc usnadnila vedení produktivních debat, ale změna starých návyků je i tak těžká. Tak jako tak je pravda, že vývojáři glibc budou muset být do hledání řešení zapojeni; dobrou zprávou je, že na toto zapojení asi dojde.

    Vývojáři Glibc nejsou známi pro lásku k rozbíjení ABI – nebo nePOSIXovým rozhraním, když už jsme u toho. Proto když se vývojář glibc Joseph Myers zapojil do debaty, tón se poněkud přesunul k řešení, které by umožnilo plynulý přechod při zachování stávajících POSIXových volání a kompatibility aplikací. Plán (který byl probrán jen nahrubo a ještě se na něm bude muset hodně pracovat) vypadá přibližně následovně:

    • Vytvořit nové, 64bitové verze dotčených systémových volání. Proto by například bylo gettimeofday64() vracející čas ve struct timeval64. Stávající verze těchto systémových volání by zůstaly beze změny.
    • Glibc by mělo nové makro s názvem jako TIME_BITS. Pokud by platilo TIME_BITS=64 na 32bitovém systému, pak by volání gettimeofday() bylo přemapováno na gettimeofday64() v rámci knihovny. Proto by aplikace mohly volitelně přejít do nového světa definováním správné hodnoty TIME_BITS.
    • Nakonec by se TIME_BITS=64 stalo výchozí hodnotou, tedy poté, co by se distribuce dodávaly v tomto režimu po nějakou dobu. I na 64bitových konfiguracích by symboly pro kompatibilitu zůstaly, aby starší binárky mohly nadále pracovat s novějšími verzemi knihovny C.

    Takový přístip by měl umožnit relativně hladký přechod na systém, který bude v roce 2038 fungovat, i když by řada nepříjemných drobností zůstala. Hovořilo se o podobném přemapování volání ioctl(), ale vypadá to jako cesta do pekel vzhledem k tomu, kolik takových volání je a jak těžké by bylo je všechna vůbec najít. Vývojáři jiných knihoven C, kteří často nemají zájem udržovat natolik rozsáhlou infrastrukturu pro komaptibilitu, jako má glibc, by možná zvolili jiný přístup. A tak dále.

    Navzdory dalším překážkám je existence přibližného plánu připraveného díky spolupráci mezi lidmi od jádra a glibc nadějí. Možná se podaří rozumně robustní řešení najít dříve, než to bude opravdu urgentní a než bude nasazeno příliš mnoho systémů, které musejí fungovat i v roce 2038. Máme příležitost předejít s relativně nízkými náklady panice v roce 2038; jestliže tuto příležitost využijeme, budeme jednou děkovat sami sobě.

           

    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ář

    10.6.2014 10:22 Andy | skóre: 17 | NMnMet
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    oprava: ... která nás čeká v lednu 2013 ...
    Válka je vůl ... a já taky ;) | Chaotic state of my influence.
    Petr Tomášek avatar 10.6.2014 11:11 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Tady koukám, že to někomu přeteklo už teď :-)
    Bedňa avatar 11.6.2014 10:49 Bedňa | skóre: 34 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Nechcem byť grammar nazi, ale tých chýb je tam viac.

    Nešlo by spraviť nejaké tlačítko "grammar nazi" a tam hádzať bugy aby to nezaplevelilo diskusiu?
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    Josef Kufner avatar 11.6.2014 22:47 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Ono by možná stačilo použít kontrolu pravopisu.
    Hello world ! Segmentation fault (core dumped)
    11.6.2014 22:59 Mti. | skóre: 31 | blog: Mti
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    To se zjevne neujalo. ;-)
    Vidim harddisk mrzuty, jehoz hlava plotny se dotyka...
    Bedňa avatar 13.6.2014 23:42 Bedňa | skóre: 34 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    :-D
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    10.6.2014 10:29 Filip Jirsák
    Rozbalit Rozbalit vše chyby v překladu
    Většina z čtenářů Jaderných novinek si je dobře vedoma zkázy, která nás čeká v lednu 2013
    Vědoma a v lednu 2038
    11.6.2014 09:12 Pepa
    Rozbalit Rozbalit vše Re: chyby v překladu
    a ještě:

    polání - volání
    10.6.2014 16:09 mankind_boost
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    polání -> volání
    10.6.2014 17:14 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Tvrzení že..
    Vývoj btrfs ukázal, že přesun prototypů systémů souborů do hlavní řady jádra nevede ke stabilitě, výkonu nebo připravenosti k produkčnímu nasazení rychleji, než když zůstanou mimo jádro, dokud není většina vývoje hotová. Začlenění do hlavní řady naopak omezuje rychlost, jakou se systém souborů může dostat do kompletního stavu a připravenosti k produkčnímu nasazení.
    ..mi přijde přinejmenším sporné, protože o produkčním nasazení souborového systému zpravidla rozhodují mnohem konzervativnější lidé, než jsou to co je spravují.

    Mám nasazeno Btrfs od té doby co je v kernelu a nikdy jsem s ním nezaznamenal problém - což bohužel nemohu říct o "produkčním" ext3. Jeho "produkční" nástupce ext4 byl začleněn ještě v horším stavu než Btrfs a během stejné doby prodělal mnohem větší kotrmelce. Přesto se bude do omrzení opakovat, že začlenění Btrfs do kernelu bylo uspěchané.
    10.6.2014 17:35 Brundibar
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    "Kapica vs kernel developeri filesystemu" 1:0. Oh, wait!

    Ignorace napr. faktu zpomalovani BTRFS v case ten problem neodstrani.
    11.6.2014 00:58 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Sorry, ale nic takového jsem zatím nepozoroval. Nehledě na fakt, že rychlost souborového systému není v případě Btrfs zrovna ta nejpodstatnější "fičura".
    11.6.2014 08:02 Logik
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    No vidíš, já jsem po půl roce utek z BRTFS, když přes to, že na něm byla polovina volnýho místa, tak mu došlo nějaký místo na inody či co a výsledkem byl totálně rozbitej balíčkovací systém.
    11.6.2014 08:43 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Zajímavé, to je zrovna věc, kterou bych čekal spíš u ext2-4.
    11.6.2014 10:20 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Na něco podobného jsem kdysi dávno také narazil, příčina ale nebyla v Btrfs, ale v tom že příkaz df blbě počítal. Jinak ano. U Btrfs na malých testovacích diskových oddílech se může stát že se zaplácne - nebo také pokud se používají kvóty. Ovšem u velkých disků má řadu páček, které umožňují podobné situaci předcházet.
    11.6.2014 11:33 logik
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    - Stejná instalace na ext4 bez problémů, takže rozhoddně to nebyla vina df.

    - A byl to relativně malý oddíl (SSD ještě rozdělené na dual-boot). A? Od filesystému čekám, že bude fungovat a ne že bude fungovat pouze za nějakých (navíc ani předem nespecifikovaných) podmínek.

    -Přesně tím se liší produkční verze od betaverze: že má vychytané takovéto "mouchy". U takového produktu typu filesystém je pak vychytání těchto much dokonce nejpracnější a zároveň nejdůležitější věc. Když bude FS geniálně navrženej, že bude o polovinu rychlejší než konkurence, ale někdy zhavaruje, tak je to prostě "křáp".
    11.6.2014 15:34 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    - Stejná instalace na ext4 bez problémů, takže rozhoddně to nebyla vina df.

    - A byl to relativně malý oddíl (SSD ještě rozdělené na dual-boot). A? Od filesystému čekám, že bude fungovat a ne že bude fungovat pouze za nějakých (navíc ani předem nespecifikovaných) podmínek.

    -Přesně tím se liší produkční verze od betaverze: že má vychytané takovéto "mouchy". U takového produktu typu filesystém je pak vychytání těchto much dokonce nejpracnější a zároveň nejdůležitější věc. Když bude FS geniálně navrženej, že bude o polovinu rychlejší než konkurence, ale někdy zhavaruje, tak je to prostě "křáp".

    No a jsme doma. Btrfs není souborový systém pro diskové oddíly menší než 1GB. Základní režie si pak ukousne víc, než kolik zbyde na data. Naopak čím větší blokové zařízení, tím efektivnější Btrfs je.

    Mimochodem KAŽDÝ souborový systém má nějakou režii některý větší a jiný menší. Dlouho jsem používal Reiserfs, protože ten měl režii bezkonkurečně nejmenší a oproti ext souborovým systémům byl i mnohem spolehlivější. Pro malé logické diskové oddíly jsem ho používal ještě loni, než ho nahradil právě Btrfs. Pro větší diskové oddíly jsem ho vyměnil za Btrfs už dříve, protože cca od 750GB výše trvala hodně dlouho kontrola po případném vynuceném restartu.

    Na ext4 a ext3 mám jen ty nejhorší vzpomínky. Několikrát jsem se nechal přesvědčit a pokaždé mě vypekly. A jednou mě to stálo i nějaká data. Přitom šlo o ext4 nad RAID6 polem, ve kterém odešel pouze jeden disk. Jen pro zajímavost - Btrfs ustálo mnohem větší kejkle nad 4TB RAID6 polem z 95% zaplněným, ze kterého vypadly 2 disky kvůli vadnému řadiči, beze ztrát.

    11.6.2014 16:07 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Dlouho jsem používal Reiserfs, protože ten měl režii bezkonkurečně nejmenší a oproti ext souborovým systémům byl i mnohem spolehlivější.
    Jak kde. Z mých zkušeností má reiserfs daleko větší sklony k samorozpadu (tj. žádné úmrtí disku) než ext3/ext4
    Quando omni flunkus moritati
    Bedňa avatar 11.6.2014 21:44 Bedňa | skóre: 34 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Ja patrím k dlhoročným užívateľom Reiseru a za tie roky som nemal jedinú zlú skúsenosť ani na jednom stroji. Dokonca mašina ktorá kolabovala niekoľko krát denne kvôli neznámej chybe Reiser stále držal konzistenciu. Potom čo nezabralo nič som tam hodil ext3 a ten sa nenávratne rosypal po prvom páde. Napokon sa ukázala chyba v radiči, tak len toľko.
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    17.6.2014 10:50 astray
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    S Reiserfs mám dobré zkušenosti, stejně jako s EXT2, EXT3, EXT4 a XFS. Btrfs jsem experimentálně používal pro lokální zálohování, ale jednoho dne systém zahlásil, že nemůže zapisovat nová data, protože je oddíl plný, i když dat tam bylo jen pár megabajtů. Další věc, se kterou mám špatné zkušenosti, je softwarový RAID. Prostě zničeho nic systém zahlásil chybu libata a bylo po datech (RAID1). Stalo se mně to dvakrát na různých strojích a od té doby dělám jen hardwarový RAID.
    12.6.2014 00:17 Mti. | skóre: 31 | blog: Mti
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    ehm... zil sem v domeni nevedomeho laika, ze od toho je raid6, aby ustal vypadek 2 disku. To snad neni "jen" frajeria filesystemu. :-) A v tom prvnim pripade to nebyl "jen" vypadek 1 disku, ze? To se totiz nemel fs vubec dozvedet. (kdyby to byl jen vypadek) To bych ciste na ext[234] nehazel. :-/

    S reiserem mam jen 1 zkusenost v ostrem provozu ... a dobra nebyla... na dalsi sem nenasel odvahu, nasledne na tom zeleze zil ROKY stejny system (debian) nad ext3 ... mam tedy tvrdit, ze ext je super a reiser uplne spatny? Jinak mam ext[34] na veskere technice a vesmes bez potizi. Urcite nic, kde bych mohl ukazat prstem jen na fs. (a nemit pri tom vycitky svedomi)

    To ze na ext3 tvra dlouho fsck...ano... skoro plne 3.6TB si vzalo skoro 2 hodiny... jenze ten stroj se resetoval tak 1x za rok... tak z toho 1x bylo s fsck.... uz se to vedelo, takze se davalo bacha, kdy se k tomu pristoupi.... no poprve to byl dobry vydrb (to se zrovna upgradovaly fw u 1TB seagatu, bo tam meli krpu... a mel sem tam 2 rady s ruznymi cd na nahrati upgrade... a mezi tim sem omylem nabootoval system... sem si pockal....tehda jen asi hodinku, bo to jeste nebylo tak plne. :-) ... ext4 je v tomto dost pohodlnejsi. Skoro to v jednm hloda, jestli to ted kotroluje poradne, kdyz to netrva tak dlouho. :-D
    Vidim harddisk mrzuty, jehoz hlava plotny se dotyka...
    12.6.2014 00:28 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    ehm... zil sem v domeni nevedomeho laika, ze od toho je raid6, aby ustal vypadek 2 disku. To snad neni "jen" frajeria filesystemu. :-)
    Ano. I já. O to nemilejší překvapení to bylo. Jinak i já mám stroje kde běží ext3 nebo ext4 Ovšem ty už takhle běží nějaký pátek. Není důvod překopávat něco co funguje.

    Jinak pokud bych měl FS ze kterého bych potřeboval distribuovat image disků virtualizovaných strojů, tak bych také šáhnul po jiném FS než je Btrfs. Ten se na uložení často modifikovaných velkých souborů nehodí. Zato pod NFS u diskless systémů nemá chybu!
    pavlix avatar 12.6.2014 08:51 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Jinak pokud bych měl FS ze kterého bych potřeboval distribuovat image disků virtualizovaných strojů, tak bych také šáhnul po jiném FS než je Btrfs. Ten se na uložení často modifikovaných velkých souborů nehodí. Zato pod NFS u diskless systémů nemá chybu!
    Pokud na strojích používáš NFS, pak mě nenapadá, kdy bys vůbec potřeboval modifikovat nějaký diskový image.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    12.6.2014 09:23 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Nemám jen jeden stroj. ;-)
    Josef Kufner avatar 12.6.2014 20:22 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Proto jsem v domácím serveru posunul nastavení sítě a spuštění sshd ještě před mount ostatních disků.
    Hello world ! Segmentation fault (core dumped)
    12.6.2014 11:23 logik
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Zas tak malý oddíl to nebyl, nepamatuji si přesně, ale řádově desítky gigabajtů se standardní instalací ubuntu. Prostě něco, kde by to mělo normálně fungovat.

    Pokud FS neustál výpadek disku u RAID 6, tak to není chyba FS, ten ale chyba řadiče. FS by takový výpadek vůbec neměl zaznamenat, protože řadič by měl furt dávat filesystému k dispozici funkční blokové zařízení.
    12.6.2014 11:23 logik
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Zas tak malý oddíl to nebyl, nepamatuji si přesně, ale řádově desítky gigabajtů se standardní instalací ubuntu. Prostě něco, kde by to mělo normálně fungovat.

    Pokud FS neustál výpadek dvou disků u RAID 6, tak to není chyba FS, ten ale chyba řadiče, FS by takový výpadek vůbec neměl zaznamenat, protože řadič by měl furt dávat filesystému k dispozici funkční blokové zařízení.
    Heron avatar 11.6.2014 10:11 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    BTRFS používám (trvale) od roku 2011, (rok před tím to bylo lehké oťukávání a testování) a žádné zpomalení jsem za ty tři, čtyři roky nepozoroval. Naopak, BTRFS přináší s sebou vlastnosti, které, pokud se používají, z něj dělá jeden z nejrychlejších FS.
    11.6.2014 12:26 Kozzi
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Prave naopak, pokud se nepouzivaji tak se jedna o docela rychly FS. Jakmile se zacne pouzivat snapshotovani tak je to po urcite dobe konec. BTRFS je zatim nepouzitelny. Ve srovnanim se ZFS je to jen hracka.
    Heron avatar 11.6.2014 12:43 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Byly doby, kdy jsem dělal snaphosty všech subvolumes 1x za hodinu a skladoval jsem v jednom okamžiku tisice snapshotů (více méně jen z důvodu, že to jde a jako test, co to vydrží). Dneska jsou to dva denně (a jedná se pořád o stejný FS od toho roku 2011). Opět, žádné zpomalení, naopak ty snapshoty přinesly zrychlení jedné činnosti. (Aneb jak rychle kdo umí zkopírovat 300GB dat, já mám za 1s snapshot, se kterým si můžu dělat co chci.)
    11.6.2014 12:59 treti pylon
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Cekal bych, ze kdyz to jednomu funguje a druhemu ne, aspon nekoho z vas napadne sem napsat i distro, kernel apod. Jinak je z toho jen drbarna.
    11.6.2014 14:28 Puk
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Netřeba se opakovat. Problémy tu jsou a nadšenci na abíčku vám data nevrátí. Red Hat moc dobře ví proč v RHEL 7 je to stále jen TP a ignorovat tvrzení jaderných vývojářů, že je to stále nehotové, může snad jen ... ignorant.

    11.6.2014 15:41 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Relevantnější link by nebyl? Jardík je zde vcelku profláknutá osoba, které snad nefunguje nikdy nic.

    Nevím jestli sis toho všimnul, tak my co ho používáme nejsme anonymní, takže se dá hravě dohledat co, kde a jak dlouho a na čem děláme. Myslím, že do kategorie "nadšenec na ábičku", co si ucvrnkává z toho jak svižně mu linux proti widlím na netbooku šlape, nespadáme.
    Heron avatar 11.6.2014 15:43 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Problémy tu jsou a nadšenci na abíčku vám data nevrátí.

    Data vám vrátí záloha (stejně jako u havárie hw, kterému žádný fs nezabrání).

    ignorovat tvrzení jaderných vývojářů, že je to stále nehotové, může snad jen ... ignorant

    Na tom se shodneme. Admin je od toho, aby to posoudil. Výsledkem je, že ono to v praxi funguje a přináší to značné zjednodušení některých operací. Já jsem s BTRFS nikdy o žádná data nepřišel, což se o některých jiných FS říct nedá, a ve chvílích, kdy selhal HW, jsem stejně vytáhl zálohu. Tedy ano, "nehotový" produkt se v praxi osvědčuje už teď.

    Jinak odkazovaný blog ..., jediná informace je "pomalost". No to jsme se toho dozvěděli. O ztrátě dat ani slovo.

    11.6.2014 16:08 lambada
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Zde pisou:
    Don't use the linux filesystem btrfs on the host for the image files. It will result in low IO performance. The kvm guest may even freeze when high IO traffic is done on the guest.
    Image file ne, rozumim. Ale co oddil? (nemam s btrfs zadne zkusenosti) Da se btrfs (ci presneji raid1 s checksumy) vyuzit pro hostovani oddilu pro KVM guesta?

    Dik
    Heron avatar 11.6.2014 16:19 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Nedá, export blokového zařízení (samozřejmně, soubor je také blokové zařízení, ale souboru se chceme vyhnout) nad nějakou storage vrstvou umí (AFAIK) ZFS, BTRFS je "jen" FS.

    Takže na oddíly pro KVM je nejlepší použít obyčejné LVM.

    Co jsem nezkoušel je připojení btrfs s volbou nodatacow (ale to potom neumí ani checksumy), nebo atribut souboru nocow.

    Jinak podle mě storage se nedá ochcat, ten výkon je daný hw a když někdo napíše low io performance, tak mi zazvoní zvonek pozor, někdo spoléhá na bůh ví jaké cachování v bůh ví čem. Ano, btrfs má poněkud pomalejší fsync, ale když to vím, tak s tím umím pracovat (nebo ten storage na to připravit).
    11.6.2014 16:38 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Já jsem obešel problém s blokovymi zařízeními u virtuálů tak, že jsou všechny stroje diskless. A sdílený disk s daty používá Btrfs.
    16.6.2014 02:45 kdave
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje

    Co jsem nezkoušel je připojení btrfs s volbou nodatacow (ale to potom neumí ani checksumy), nebo atribut souboru nocow.
    Soubory s NOCOW atributem se na image virtualnich stroju daji (a maji) pouzit a vykon se vrati do normalnich mezi. Nove qemu pro to ma uz snad podporu.

    Pokud jsou image oddelene v jednom adresari, tak staci nastavit NOCOW atribut na ten adresar a vsechny nove vytvorene soubory ho zdedi (presunute do toho adresare ne).
    16.6.2014 10:15 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Zajímavá informace..
    11.6.2014 21:26 Vladimír Čunát | skóre: 19
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Jo, Btrfs mi při velkém průtoku dat přes relativně zaplněný disk znatelně zpomaluje po pár měsících/letech, nejspíš kvůli fragmentaci (5400rpm HDD). Na druhou stranu, se správným nastavením a defragmentací některých částí to není tak špatný.
    11.6.2014 21:46 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Btrfs má několik metod, jak si s takovou situací za běhu poradit. To je to co se mi na něm líbí. Fakt ovšem je, že pokud to někdo nemá odzkoušené, tak se toho - po zkušenostech s jinými fs - bojí. Asi tak jako já zpočátku.
    16.6.2014 03:13 kdave
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Nedovedu si moc predstavit, ze by vyvoj mimo mainline mel za nasledek rychlejsi stabilizaci. Hodnekrat jsem byl svedkem situaci, kdy vyvojarum vsechno funguje, ale dostavaji reporty od uzivatelu, ze je neco rozbite a jim se to nedari zreprodukovat.

    Kde nejsou uzivatele, nejsou prirozene chyby a vsechno je stabilni. Spise jde o to, jak zdravy je cyklus chyba -> oprava -> release. Tady bych rekl, ze to u btrfs neni stale ono, coz je podle me motivace pro to tvrzeni.

    Na druhou stranu je tezke nezanaset nove a nove chyby, kdyz pribyvaji featury, zvlast ty s tendencemi hrabat uplne do vseho. Obvykle to zabere 2-3 releasy nez se to vychyta, nekdy i dele, kdyz je potreba udelat rewrite.

    Kdyz uz je neco v mainline, byva to o par kroku snadnejsi to zacit pouzivat nez v pripade, ze je potreba kdesi najit a stahnout zdrojaky/patche, patchovat (a doufat ze to zrovna na tuhle verzi pujde) pripadne resit byt jen trivialni konflikty. A takovehle "prkotiny" muzou odpuzovat statecne testery. Zapnout config option zvladne mnohem vic lidi.
    16.6.2014 10:16 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Svatá pravda. Rozumná řeč.
    16.6.2014 16:41 ebik | skóre: 2
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Ano, ale také je to o pár kroků snadnější používat pro někoho, kdo neví co dělá, a pak dělá filesystému negativní reklamu, protože mu to nefunguje. Také vznikne mezi laiky zmatení od které verze že už to jako funguje (zvlášť, když funkčnost je relativní pojem, vzhledem k požadavkům daného uživatele). Vývojáři ostatních FS musí při navrhovaných změnách obecných funkcí (VFS) dávat pozor aby nerozbili FS, který vlastné není stabilní (a musí to ve svých patchích řešit). Proto by také featury měli být na vývojovém stromě a do releasu jít až po řádném otestování. Nevím jak je na tom btrfs s vývojem teď, nicméně věřím, že když je výběr z několika funkčních (unixových) filesystémů, není potřeba se začleňováním dalšího FS spěchat.
    little.owl avatar 17.6.2014 16:56 little.owl | skóre: 22 | Brighton
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    +1
    You're damned if you do, and you're damned if you don't.
    10.6.2014 21:40 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    "čekajících front"? Když už se to mermomocí musí pro zmatení nepřítele překládat, proč ne aspoň "čekacích"?
    11.6.2014 19:16 olin
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Ony ty fronty asi pořád na něco čekají a nejsou nikdy prázdné...
    11.6.2014 07:11 MN
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Asi mi neco tak uplne nedoslo, ale proc maji tyhle zpravicky skoro 3 tydny skluz?
    11.6.2014 07:34 ebik | skóre: 2
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Výživná diskuze zde, odkaz by měl vést na nejrelevantnější příspěvek

    http://www.abclinuxu.cz/clanky/jaderne-noviny-3.-4.-2014-diskove-bloky-vetsi-nez-4k/diskuse#12
    Marián Kyral avatar 11.6.2014 09:54 Marián Kyral | skóre: 29 | blog: Sem_Tam | Frýdek-Místek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Sis asi nevšiml, ale tohle není zprávička ;-)
    11.6.2014 10:36 ebik | skóre: 2
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Myslím, že tím tazatel nemyslel "Zprávičky" v boxu vlevo ale prostě "zprávičky" jako synonymum slova "novinky"/"noviny".
    11.6.2014 10:57 frr | skóre: 33
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014 - citáty
    Dnešní pýtické citáty mě donutily následovat link a přečíst si kontext. A tušil jsem správně, opět byl mnohem výživnější celý kontext, než samotný "vtipný" citát :-)

    První dva citáty jsou z jediného vlákna v mailing listu, kde se pár lidí baví o tom, jestli by nešlo "full nohz" zapínat/vypínat per CPU core, nejlépe za chodu. Ono to má vliv na RT odezvu vs. rychlost obsluhy syscallů. Na stroji, který dělá několik různých věcí (různé typy úloh), by to mohla být zajímavá vlastnost. V tom vláknu je dále zajímavé, jak se pánové občas baví "o voze a o koze" :-) ale nakonec se zřejmě domluvili.

    Třetí citát je z jedné dlouhé zprávy, která obsahuje podobných hlodů několik. Můj další kandidát na dobře mířený hlod je "Thusly does kerneldoc bitrot." Jinak je to o nějakém ladění v MM, jde o drobnou optimalizaci čehosi s ohledem na efektivitu práce s kešemi v multicore CPU...
    [:wq]
    12.6.2014 18:08 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Taky si rypnu do prekladu - IMHO prekladat 'review' v tomto vyznamu a kontextu jako 'revidovat' je zavadejici. To uplne posouva vyznam. Lepsi preklad by byl 'recenzovat' nebo jeste lepe 'posuzovat'.
    12.6.2014 19:07 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    BTW, myslel jsem, ze 'revidovat' je jeden z mnoha vyznamu 'review' a prekladatel to jen otrocky prelozil, ale zrejme tomu tak neni, 'revidovat' ma anglicky ekvivalent v 'revise', coz dela preklad 'review' na 'revidovat' jeste nepochopitelnejsim.
    13.6.2014 14:19 niobi | skóre: 10 | blog: Niobi w3b.1og | Liberec city
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    Koukam někomu time_t už pretekl v lednu 2013 :-D
    Totalni paranoia Linuxaka: emerge -C windows-base/windowsXP-meta MAC-WAR.eu - aneb i na apple je warez :-P
    17.6.2014 18:56 JZD | skóre: 9 | blog: Na_dvorku
    Rozbalit Rozbalit vše Re: Jaderné noviny – 22. 5. 2014: Systém souborů Tux3 se reviduje
    s/přístip/přístup/
    Víra znamená vyznávat to, o čem člověk dobře ví, že to není pravda. Mlčeti platina, mluviti v gajzu, býti v hajzlu.

    Založit nové vláknoNahoru

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