Jaderné noviny – 4. 9. 2014: Systémy souborů v trvalé paměti

24. 9. 2014 | Tadeáš Pelech | Jaderné noviny | 3974×

Aktuální verze vývojového jádra: 3.17-rc3. Citáty týdne. Podpora systémů souborů v trvalé paměti.

Obsah

• Aktuální verze vývojového jádra: 3.17-rc3
• Citáty týdne
• Podpora systémů souborů v trvalé paměti

Aktuální verze vývojového jádra: 3.17-rc3

Vývojové jádro 3.17-rc3 vyšlo dne 31. srpna (oznámení). Linus k tomu řekl:

Podle očekávání je větší než rc2, protože se všichni zjevně vrátili z Kernel Summitu a tak. Naštěstí ale není o tolik větší než rc2 a neděje se nic tak zvláštního, takže prostě budu ignorovat všechny ty námitky o létě a doufám, že všechno půjde dobře.

Stabilní aktualizace: Minulý týden nebyla vydána žádná. Aktualizace 3.16.2, 3.14.18 a 3.10.54 procházejí v době psaní tohoto textu procesem revizí, můžeme je čekat 5. září nebo o něco později.

Citáty týdne

Bojím se jednoho – že nám unikají regrese výkonu, protože nové verze obsahují zisky i ztráty výkonu, z nichž některé se vyvažují. Po vydání řady hlavních verzí se výkon může zdát v pořádku, ale ve srovnání s vyzobáváním třešniček v distribučním jádru není situace zase tak růžová.

Mel Gorman (odkaz)

Řešení problému je úplně špatné a samozřejmě „oprava“ se použije jen na tu jednu instanci, které se ten problém může týkat, tedy té, která způsobila potíže tomu, kdo opravu předložil.
Nemám to za zlé autorovi, viním správce, který tu „opravu“ bez řečí zavedl.
To je bohužel v jádru velmi běžný jev, který z dlouhodobého hlediska způsobí vážné problémy s udržovatelností, ale to je samozřejmě jen názor jednoho nevrlého starého dědka.

Thomas Gleixner (odkaz)

Moje schránka doručené pošty vypadá, jako by se srazily dva poštovní vlaky přepravující e-maily a pak se na ně ještě zřítilo letadlo s nákladem e-mailů.

Matthew Garrett (odkaz)

Podpora systémů souborů v trvalé paměti

Pár let už slýcháme, že nastupující zařízení s energeticky nezávislou pamětí (non-volatile memory, NVM) změní způsob našeho používání počítačů. Tahle zařízení by měla nabízet velké objemy paměti (pravděpodobně v řádu terabajtů), která je trvalá a přitom k ní lze přistupovat stejně rychle jako k pamětem RAM. Co s tak velkou trvalou pamětí budeme dělat, zatím není jasné, začíná se jí ale věnovat pozornost. Zdá se, že v ní budeme používat klasické systémy souborů. Bude je ale nutné poupravit, aby mohli uživatelé využít plný výkon NVM.

Je hračka na disk z NVM nasadit blokový ovladač zařízení tak, aby se tvářil jako každý jiný disk. V takovém případě se ale všechna data na disku kopírují do stránky ve vyrovnávací paměti jádra a zpět. Protože jde ale k datům přistupovat přímo, tohle kopírování je přinejmenším neefektivní. Uživatelé preferující výkon se raději chtějí vyhnout stránkování ve vyrovnávací paměti, kdykoli je to možné, aby mohli z disků NVM získat maximální možný výkon.

Jádro obsahuje nějakou podporu přímého přístupu do energeticky nezávislé paměti už od roku 2005, kdy byla do systému souborů ext2 přidána podpora XIP (execute-in-place). Tento kód umožňuje namapování souborů z přímo přístupného zařízení do uživatelského prostoru a data tak nemusejí procházet stránkovací vyrovnávací pamětí. Kód XIP se ale zjevně příliš nepoužívá a několik let se nevylepšuje, takže se současnými systémy souborů nefunguje.

Matthew Wilcox začal loni pracovat na vylepšení kódu XIP a jeho integraci do systému souborů ext4. Při tom zjistil, že není příliš vhodný pro potřeby současných systémů souborů; kód také obsahuje řadu nepříjemných konfliktů časování. A tak se jeho práce postupně změnila z rozšíření XIP na jeho náhradu. Jeho práce, v současnosti ve formě 21dílné sady oprav, se přibližuje stavu, kdy ho bude možné sloužit s hlavní větví. Dá se tedy čekat, že upoutá větší pozornost.

Tyto opravy nahrazují kód XIP novým subsystémem nazvaným DAX (tedy Direct Access, přímý přístup). Na úrovni blokového zařízení nahrazuje stávající funkci direct_access() ve struktuře block_device_operations.

Tato funkce přijímá číslo sektoru a hodnotu velikosti informující ke kolika bajtům chce volající získat přístup. Pokud je daný prostor přístupný přímo, měla by být vrácena základní adresa (jádra) a příslušné číslo rámce stránky. Číslo rámce stránky by se mělo použít v tabulce stránek při zajišťování přímého přístupu z prostoru uživatele do paměti.

Použití čísel rámců stránek a adres se může zdát trochu divné; většina jádra na téhle úrovni pracuje s pamětí pomocí stránky struktury. To zde ale z jednoho prostého důvodu nelze uplatnit: NVM není obyčejná RAM a nemá asociované žádné struktury stránek. Tyhle chybějící struktury mají řadu důsledků; asi nejvýznamnější je skutečnost, že NVM nelze kvůli přímému přístupu do paměti přenést do jiného zařízení. To například vylučuje nulové kopírování vstupně-výstupních síťových operací se souborem uloženým v zařízení NVM. Boaz Harrosh pracuje na sadě oprav umožňujících použití struktur stránek s NVM, nachází se ale zatím v poměrně rané fázi.

O jednu vrstvu výše se věnuje docela dost energie při prosazení podpory NVM ve vrstvě virtuálních systémů souborů, kterou by mohly používat všechny systémy souborů. Prozatím se připravuje zavedení podpory tohoto mechanismu do systému souborů ext4.

Andrew Morton je ale k téhle aktivitě poněkud skeptický. Jednou z prvních otázek je: proč nepoužít „vhodně upravenou“ verzi systému souborů v paměti (například ramfs nebo tmpfs). Bohužel se ale ukazuje, že tyto systémy souborů jsou připraveny pro paměti typu RAM, zatímco v případě typu NVM vhodné nejsou.

Podle Dava už jádro obsahuje pár „implementací trvalé paměti“, které potřeby NVM splní – systémy souborů XFS a ext4. Oba mohou hned pracovat s blokovými zařízeními využívajícími trvalou paměť. Chybí jim pouze možnost přímého mapování souborů do uživatelského prostoru bez použití stránkovací vyrovnávací paměti. A to by měl řešit právě kód DAX.

Existují i skupiny pracující na systémech souborů navržených přímo pro NVM, většina jejich práce je ale v počáteční fázi. Pokud všechno bude pokračovat stejně, dočkáme se jejich implementace do jádra nejdříve za několik let. Proto lze předpokládat, že si uživatelé disků z NVM vyberou některý ze stávajících systémů souborů.

       

Komentáře

[Michal2]

Ja si myslim, ze NVM povede k celkove zmene paradigmatu a zpusobu, jakym pracuji nejen FS ale OS jako celek. Tudiz pristupovat k problemu stylem "Zdá se, že v ní budeme používat klasické systémy souborů." zda se mi byti ponekud nestastnym.

[frr]

Futuretro. Návrat do 8bitové éry - žádný FS, všechno běží rovnou z ROMky (zde NVRAM). Na takto primitivním OS rozjet browser s minimální sadou vlastností, dostačující pro Facebook. A druhá varianta bude optimalizovaná jako superlevný minimalistický podvozek pro cloud. K čemu nějaký systém souborů. K čemu soubory. Jo a té NVRAMky ať je aspoň terabajt, aby bylo kam archivovat předchozí verze instalátoru toho browseru (a iTunes, a PDF readeru, a Javy...). A nakonec: hlavně aby to mělo na displeji multitouch senzor ... a 4k rozlišení, aby ty tři ikony pro slepce co se na displej vejdou měly hezky hladké hrany.

Omlouvám se, neberte si to osobně tohle ve mně vyvolává zmínka o změně paradigmatu...

[dvcasxcasdc]

je to zmena vzhledem k poslednim 20 rokum.

pocitac jednou nabootuje a pak uz vsecko pobezi z nvram, nebude rozdil mezi diskem a ramkou.

[Libor Chocholaty]

Takovy system bych chtel videt. Mozna bych se mel na pul hodiny zamyslet a nechat si to patentovat.

[vlastikroot]

Ta NVRAM bude pripojena stejnou sbernici jako je dneska RAM? Pak je to jednoduchy, udela se RAMdisk. A kdyz ne, je to max. jako swap. Nic se nemeni.

[frr]

Taky to na mě zatím tak působí.

Ono se tady tuším o tom už jednou debatovalo, když s tím nápadem HP vylezlo na denní světlo - a vybavuji si jedinou konkrétní zmínku, jak rychlá ta RERAM má doopravdy být. Padlo tuším číslo ve vysokých desítkách ns - neznělo to jako dnešní DRAM, spíš jako dnešní flash (akorát bez řádek a erase bloků) -> muselo by to mít přinejmenším další patro cache, řádově větší než dnešní L3 SRAM cache on-chip v CPU. Taky si nejsem jist, jak by se to mechanicky / pinoutově / elektricky vešlo do DIMM slotů, jak je známe dnes. Čili je myslím otázkou, jestli to bude připojené skutečně skrz dnešní řadič RAM, nebo skrz PCI-e (s nějakým skoro přímým mapováním do prostoru hostitelovy RAM), nebo nedejbože skrz nějakou diskovou sběrnici (SATA - viz dnešní SSDčka v PCI-e).

Pokud by to chtěli připojit přímo na řadič RAM, tak bude třeba přeskupit hierarchii keší, aby to fungovalo aspoň trochu důstojně... a čtvrté patro keše už se na procesor nevejde... takže z toho vychází další DIMM sběrnice pro cache? Nebo "tykadla vystrčená z CPU" = předsunuté řadiče cache DIMM + RERAM DIMM?

[vlastikroot]

Jestli je to tak pomaly, vidim jako optimalni cestu pridavnou PCI-e kartu - na ty muze byt treba DRAM cache, nebo nemusi byt vubec a pouzije se jako cache systemova RAM.

[Michal2]

In May 2012 it was reported that access time had been improved to 90 nanoseconds if not faster, approximately one hundred times faster than contemporaneous flash memory, while using one percent as much energy

Pokud spravne pocitam, tak 1600 ddr3 ma frekvenci 800, CAS 8 a vic takze ma access time 20 ns.

[Conscript89]

Ne tak docela, je to uz zmineny v clanku. V takovym pripade by probehlo nacteni binarek z jednoho mista NVRAM do druhyho a pak teprve spustilo, coz asi nechces.

[vlastikroot]

To je preci uz minimalni zmena, zajistit, aby se to zbytecne nekopirovalo. Neznamena to preci zrusit filesystemy atd jak je to v komentu nade mnou.

[omg]

o to ale ve zprave nejde. tam jde o vynechani copy-on-read cyklu do ram. to ze filesystem by sel uplne vyhodit a vsechno pribalit do patricnych elf sekci a kompletni fs io operace v userspace hijacknout vhodnym preloadem nebo statickym linkovanim to uz urcite napadlo nekoho i driv nez me zhruba pred rokem.

[frr]

Souhlas, nejde Reagoval jsem na předřečníka. Nicméně, ukládat data o dynamické délce do sekcí ELFové binárky... myslím jako alternativa FS... no nevím... nebo možná špatně chápu

[retroslava]

Našel jsem malej překlepík.

Nemám to za zlé autorovi, viním správce, který tu „opravu“ bez řeší zavedl.

Jinak já bych to přeložil víc podle originálu.

Nemám to za zlé autorovi, viním správce, který tu „opravu“ vesele zavedl.

[alkoholik]

Jeste tam ma přímý pčístup

[Václav "Darm" Novák]

Tak má kašel, no…

[Aleš Kapica]

Podpora systémů souborů v trvalé paměti...

Kdyby raději konečně přijali do hlavní vývojové větve overlayfs nebo aufs. Případně obě řešení - aby si mohl vybrat každý co mu lépe vyhovuje. Udělali by lépe.

[Michal Kubeček]

A kdo jsou ti tajemní oni, smím-li se zeptat?

[x14]

Přece Linuxináti!

[trekker.dk]

Problém je v tom, že AFAIK overlay filesystémy mají vždycky nějaký ten nedořešený háček a v případě aufs IIRC taky pěkně naprasený kód. Proto to není v mainline.

[Michal Kubeček]

…a tak je to ostatně s většinou featur, o kterých se pravidelně naznačuje v diskusích, že jakési temné síly brání jejich přijetí do mainline. U některých dokonce ani žádný pull request nikdy nebyl.

[Aleš Kapica]

Tohle není argument, ale plácnutí do vody. V kernelu je řada věcí v mnohem horším stavu než zrovna tohle. Víc by o tom mohl napsat kolega. Já se v kernelu zas tak do hloubky nehrabu.

[Michal Kubeček]

Tohle není argument, ale plácnutí do vody.

Ne. To je zcela zásadní argument. Byl v případě ReiserFS a je i v případě jakékoli jiné cool, ale nedotažené featury. Je mi jasné, že tento argument nezní dost přesvědčivě pro zástup lidí, kteří se vývojem jádra - a zejména hledáním chyb v něm - nezabývají, ale zato mají hromadu zkušeností typu "používám to už n let a prostě mi to funguje". Ale oni naštěstí nejsou tím, kdo rozhoduje, co bude v mainline.

V kernelu je řada věcí v mnohem horším stavu než zrovna tohle.

To, že je z historických důvodů v jádře kód, který je ošklivý a problematický, v žádném případě neospravedlňuje bezhlavé přidávání dalšího. Navíc se to až na řídké výjimky vesměs týká spíš koncových driverů zařízení. Filesystém je něco trochu jiného a pravidla jsou tam mnohem přísnější. Ne náhodou je poškození filesystému považováno za závažnější typ chyby než úplný pád systému.

[Aleš Kapica]

Jasně. Jako byl v okamžiku přidání skvěle dotažený ext4.

Tenhle argument by možná dával smysl, kdyby existovala alternativa. Osobně mám dojem že se nové věci do jádra přidávají spíš z pozice ekonomické síly jejich vendora než kvality.

[Michal Kubeček]

Jasně. Jako byl v okamžiku přidání skvěle dotažený ext4.

Máte nějaké konkrétní příklady obtížně udržovatelného kódu nebo (v té době) známých vážných chyb, nebo jde jen o - vašimi slovy - "plácnutí do vody"?

Osobně mám dojem že se nové věci do jádra přidávají spíš z pozice ekonomické síly jejich vendora než kvality.

Na základě čeho máte ten pocit? Pokud za něčím stojí ekonomicky silný subjekt, tak to samozřejmě hraje roli, ale spíš nepřímo: je pochopitelně jednodušší něco rozsáhlejšího vyvinout a dotáhnout do akceptovatelné podoby, pokud někdo zaplatí vývojáře, kteří by se tomu naplno věnovali.

Obávám se, že podobné konspirační teorie o tom, jak jacísi tajemní "oni" zlovolně brání začlenění užitečných featur do jádra, jsou jen názorným příkladem pravidla "čím méně toho o problematice vím, tím snazší je mít o ní jasno". Jakmile si dohledáte konkrétní pull requesty, námitky maintainerů a důvody odmítnutí, začne se ukazovat, že je to vlastně celé trochu jinak.

[Aleš Kapica]

Jeden historický bud jen tak namátkou.

Na základě čeho mám ten pocit? Věci za kterými stojí velké firmy (Red Hat, Oracle, Google) se dostaly do kernelu celkem bez keců poměrně rychle - přes to, že jejich použitelnost byla diskutabilní.

Aufs je s námi už poměrně dost dlouhou dobu, ale protože za jeho vývojem nestojí velká firma, tak v jádře stále není. Přitom nic nebrání tomu, aby to bylo přidané jako experimentální modul. Ale budiž. souhlasím s tím, že aufs není udělané zrova čistě. Pokud jde o overlayfs, tak podle toho co vím jde o věc napsanou přímo dle doporučení vývojářů kernelu. O zařazení se uvažovalo již u jádra 3.10 Dnes se připravuje jádro 3.17 a stále není začleněno ani jedno řešení. U nás využíváme overlay poměrně hodně, takže předpokládám, že pokud by mělo jedno, nebo druhé řešení nějaké zásadní bugy, tak by se to nejspíš projevilo.

[trekker.dk]

Jeden historický bud jen tak namátkou.

Hádám, že jste se asi neobtěžoval přečíst si, v čem ten bug spočíval, že ne? Ten "bug ve filesystému" byl ve skutečnosti chybou aplikací, které nesprávně očekávaly nějaké specifické chování, v tomto případě že soubor je na disk zapsán okamžitě poté, co ho aplikace uzavře. Takové očekávání je chybné, protože nic takového garantováno není a pokud aplikace chce mít soubor skutečně okamžitě zapsaný na disk, musí si o to říct například pomocí fsync().

Opravovalo se to ve filesystému - pouhou změnou výchozího nasstavení IIRC - protože takhlě blbě napsaných aplikací bylo moc.

Věci za kterými stojí velké firmy (Red Hat, Oracle, Google) se dostaly do kernelu celkem bez keců poměrně rychle - přes to, že jejich použitelnost byla diskutabilní.

Určitě máte nějaký příklad, že? Včetně té diskutabilní použitelnosti, prosil bych.

Aufs je s námi už poměrně dost dlouhou dobu, ale protože za jeho vývojem nestojí velká firma, tak v jádře stále není.

Zatímco fakt, že je to 16000 nebo kolik řádků totálně nepřehledného kódu, ve kterém se vyzná asi tak jeden člověk, žádnou souvislost nemá...

Přitom nic nebrání tomu, aby to bylo přidané jako experimentální modul.

Jakmile se to jednou dostane do jádra, musí se o to někdo starat. To brání tomu, aby to bylo přidáno jako experimentální modul. Slovo experimentální na tom nic nemění.

Pokud jde o overlayfs, tak podle toho co vím jde o věc napsanou přímo dle doporučení vývojářů kernelu. O zařazení se uvažovalo již u jádra 3.10 Dnes se připravuje jádro 3.17 a stále není začleněno ani jedno řešení.

Podle rychlého googlení se na overlayfs stále pracuje - když o něj tak stojíte v mainline, můžete pomoci.

[Michal Kubeček]

Věci za kterými stojí velké firmy (Red Hat, Oracle, Google) se dostaly do kernelu celkem bez keců poměrně rychle - přes to, že jejich použitelnost byla diskutabilní.

Příklad? To, že vy osobně něco považujete za těžko použitelného, zdaleka neznamená, že to nemůže být velmi užitečné pro druhé. Myslíte snad, že ty firmy, které jste jmenoval, jen tak pro zábavu financují vývoj něčeho, co nemají v úmyslu používat? Občas samozřejmě ano, ale většinou se investuje do toho, co má zřejmý smysl.

A hlavně: užitečnost je jen jednou z podmínek pro to, aby se kód dostal do mainline.

O zařazení se uvažovalo již u jádra 3.10 Dnes se připravuje jádro 3.17 a stále není začleněno ani jedno řešení.

Nepíšete ovšem proč. Díval jste se, jestli od té doby byly nějaké pull requesty, a pokud ano, jak bylo zdůvodněno zamítnutí?

předpokládám, že pokud by mělo jedno, nebo druhé řešení nějaké zásadní bugy, tak by se to nejspíš projevilo

To je velmi odvážný předpoklad. Linux se dnes používá na extrémně širokém spektru zařízení a velmi rozmanitými způsoby. Jsou chyby, které se projevují jen na určitých architekturách, jen s mnoha procesory (což pro někoho nemusí znamenat 64, ale spíš 4096), spoustou paměti nebo třeba mnoha SCSI zařízeními.

Mimochodem, jádro 3.10 vyšlo před necelými 15 měsíci. Z hlediska vývoje něčeho tak komplexního to není až tak dávno, jak to na první pohled vypadá.

[Aleš Kapica]

Já přeci nemám nic proti tomu, že se do jádra přidávají věci důležité pro jiné, a které osobně nepoužívám. Mě vadí to, že se tam nepřidají také ty věci, co používám já. Nejspíš nebudu sám, kdo je využívá jinak by asi aufs nebylo standardní součástí distribučního jádra debianu.

Pokud jde o to proč k začleněnění dosud nedošlo, mohu čerpat pouze informace z druhé ruky. Nejsem vývojář kernelu a na sledování komunikace o tom co se kde šustne nemám čas. Mě nedělá problém si čas od času kernel opatchovat, ale soudím že vývoj a údržba takových věcí mimo hlavní vývojovou větev sebou nutně nese opruz navíc. A řekl bych že v případě některých technologií je to spíš otázka politiky než zdrojového kódu. Z toho co vím se o to, že zatím k začlenění overlayfs nedošlo nejvíc zasloužila jedna ... která zakalila vodu a pak zase chcípnul pes. Ten týpek co stojí za overlayfs dělá ještě hafo jiných věcí, takže na pilu netlačí, Japonec se sice snaží s jádrem držet krok ale jeho kód je stále údajně fuj fuj fuj. Takže jsme v situaci, kdy v mainline není pro jistotu nic.

A sorry, na pocit, že kdo nemaže, ten do jádra nejede, mám plné právo. Ostatně bych se ani nedivil a nepohoršoval nad tím, kdyby začlenění některých věcí do kernelu provázelo zajímavé všimné na Linusův účet.

[trekker.dk]

Já přeci nemám nic proti tomu, že se do jádra přidávají věci důležité pro jiné, a které osobně nepoužívám.

To o vás ale předřečník netvrdil, že ne? Jo a ten příklad chybí...

Nejsem vývojář kernelu a na sledování komunikace o tom co se kde šustne nemám čas.

Ale když vám odpovídá člověk, který AFAIK do vývoje kernelu vidí, tak ignorujete, co říká...

Mě nedělá problém si čas od času kernel opatchovat, ale soudím že vývoj a údržba takových věcí mimo hlavní vývojovou větev sebou nutně nese opruz navíc.

Ano, je pochopitelné, že byste byl radši, kdyby ten opruz někdo řešil za vás. Jenže ten někdo vůbec nemusí být původní vývojář toho kódu, ale někdo, komu to spadlo na hlavu poté, co se původní vývojář na kód vykašlal.

A řekl bych že v případě některých technologií je to spíš otázka politiky než zdrojového kódu. Z toho co vím se o to, že zatím k začlenění overlayfs nedošlo nejvíc zasloužila jedna ... která zakalila vodu a pak zase chcípnul pes.

Takové tvrzení by bylo vhodné podložit odkazy na relevantní diskuzi třeba na LKML... jinak to není nic jiného, než to plácnutí do vody.

[Aleš Kapica]

Pokud tím člověkem co "AFAIK do vývoje kernelu vidí" máte být vy, tak by bylo na místě místo těch vágních a neustále omílaných keců o tom že ten kód nevyhovuje nárokům vývojářů jádra uvést proč nedošlo k původně avízovanému začlenění overlayfs. Pokud jde o mne, tak já mám informace o tom jak to je od člověka, o kterém vím, že vývoj jádra sleduje nad rámec čtení rešerší z LKML.

[mankind_boost]

+1

[Michal Kubeček]

Obvyklé je, že konkrétní výhrady sdělí příslušný maintainer subsystému v odpovědi na pull request (nebo sérii patchů). Pokud tomu tak v tomto případě nebylo, pak očekávám, že vy poskytnete odkaz na e-mail, kterým byl pull request zamítnut, abychom mohli posoudit, zda šlo opravdu jen o vágní výmluvy. Pokud jste tu odpověď ve skutečnosti nečetl a přesto tady stále mlžíte o temných silách a moci peněz, pak to dost vypovídá o vaší věrohodnosti.

Já jsem například jako poslední našel tohle. Al Viro tam přednesl zcela konkrétní technické výhrady. Nejsa specialistou na VFS a filesystémy, netroufám si posuzovat jejich závažnost a relevanci. Vy ano?

[trekker.dk]

Pokud tím člověkem co "AFAIK do vývoje kernelu vidí" máte být vy

Ne.

Ten příklad věcí, které "se bez keců dostaly do mainline díky podpoře velké firmy přes to, že jejich použitelnost byla diskutabilní" asi nebude, co?

[Michal Kubeček]

soudím že vývoj a údržba takových věcí mimo hlavní vývojovou větev sebou nutně nese opruz navíc

To rozhodně ano. Ale i tak tomu občas dá někdo přednost před tím, aby svůj kód upravil do akceptovatelné podoby.

Nejsem vývojář kernelu a na sledování komunikace o tom co se kde šustne nemám čas.

Přesto by neměl být takový problém, pokud vás overlayfs tak moc zajímá, dohledat příslušnou komunikaci ve veřejných archivech příslušných mailing listů. Rozhodně by to bylo přínosnější než bez dostatečných informací šířit mlhavé náznaky typu

A řekl bych že v případě některých technologií je to spíš otázka politiky než zdrojového kódu. Z toho co vím se o to, že zatím k začlenění overlayfs nedošlo nejvíc zasloužila jedna ... která zakalila vodu a pak zase chcípnul pes … ale jeho kód je stále údajně fuj fuj fuj. Takže jsme v situaci, kdy v mainline není pro jistotu nic.

A sorry, na pocit, že kdo nemaže, ten do jádra nejede, mám plné právo.

To určitě máte. Jen byste ho neměl vydávat za nic víc než za osobní pocit někoho, kdo to dění vlastně nijak moc nesleduje a ten pocit si utváří na základě kusých informací z druhé ruky.

[Aleš Kapica]

Nikdy jsem nikomu netvrdil, že to je něco víc než osobní pocit. Tak mi to laskavě nepodsouvejte. Pokud by vám činilo problém si dohledat co jsem vlastně na tohle téma hned zkraje uvedl:

Osobně mám dojem že se nové věci do jádra přidávají spíš z pozice ekonomické síly jejich vendora než kvality.

[ebik]

No a ted si predstavte jak by to vypadalo, kdyby vsechny ty velke firmy hrali pouze cistou hru: maji vyvojare, daji mu penize aby vyvinul to co potrebuji, a tyto penize venuji i na to, aby patchu zahrnul vsechny pripominky hlavnich vyvojaru kernelu. Featury, ktere tyto firmy nechteji, vyvijeji dobrovolnici ve svem volnem case a nemaji z toho nic. Navic se musi nejak zivit, takze toho volneho casu zas tolik nemaji. Je to tak diametralne odlisne od toho co vnimate?

[Aleš Kapica]

Není. Právě proto mi to vadí. Brzdí to jejich vývoj. Začlenění do mainline podle mě výrazně zvyšuje šanci na to, že se najde někdo, kdo případné bugy najde, případně ne příliš dobrý kód napíše jinak a lépe.

Abych byl konkrétní - jsem autorem jedné z extension MediaWiki. Od začátku jsem kód udržoval v gitu a také jsem využil první příležitosti, abych ho začlenil do oficiálního repozitáře. Kdybych to neudělal, tak bych musel veškeré drobné změny opravovat sám a na to opravdu čas nemám. Na rozdíl od jiných borců můj multitasking není z nejrychlejších, takže dělám věci dávkově. Proto také ignoruji trekkerovy a Kubečkovy výzvy abych dohledával věci, které momentálně stojí zcela mimo moji pozornost.

[Michal Kubeček]

Proto také ignoruji trekkerovy a Kubečkovy výzvy abych dohledával věci, které momentálně stojí zcela mimo moji pozornost.

Aha. Takže na jedné straně vás overlayfs tak moc zajímá a jeho absence v mainline tak moc trápí, že po diskusích spřádáte konspirační teorie o tom, jak ho maintaineři bez vážného důvodu odmítají přijmout, ale na druhou stranu je zcela mimo vaši pozornost ověřit si, jak to je s tím (ne)začleněním ve skutečnosti (dogooglit se k tomu threadu, na který jsem odkazoval odpoledne, mi netrvalo ani pět minut). Zajímavé…

[ebik]

Jejich vývoj brzdí jen to, že není nikdo kdo by ten vývoj zaplatil. Ty člověkohodiny se tomu prostě dát musí. Kernel má vysoké nároky na kvalitu kódu (konec konců je to jádro operačního systému a ne webová stránka u které nevadí, když se zobrazí jen 99% uživatelů). Tyto vysoké nároky platí pro všechny stejně. Jen holt velké firmy mají peníze na to aby se tomu jejich vlastní vývojáři věnovali a dostali to tam rychle. A nedělejte si iluze o tom, že by tito placení vývojáři vůbec do kernelu přispívali, kdyby na to nedostali peníze.

Kdyby se tam navíc dostal kód tak rychle jak navrhujete, tak by se výrazně zpomalil vývoj ostatních (a někdy i nesouvisejících) věcí, kvůli tomu, že by hlavní vývojáři museli navíc řešit kompatibilitu s neodladěným (tedy potenciálně chybným) kódem. Představte si to jako středně rychle jedoucí autobus s otevřenými dveřmi, do kterého kdo chce a kdy chce nastoupí a vystoupí. Vy byste tam chtěl mít za jízdy jukebox. Dokonce jeden máte. Jen nemáte auto kterým byste ho k tomu autobusu dopravil a za jízdy přeložil do něj. Tak navrhujete aby kvůli vám ten autobus zastavil, a počkal až tam ten jukebox dotáhnete holýma rukama.

[trekker.dk]

Začlenění do mainline podle mě výrazně zvyšuje šanci na to, že se najde někdo, kdo případné bugy najde, případně ne příliš dobrý kód napíše jinak a lépe.

Ano, tuhle teorii zastávali i jiní. Zkusilo se to u btrfs a ukázalo se, že to zase tak moc dobře nefunguje, vývoji se pak stejně věnovali víceméně ti samí lidé, které tenkrát platil Oracle. Se stejnou myšlenkou vznikl staging strom a taky to není žádný zázrak. Proto na tenhle argument vývojáři mainline už neslyší, i přesto že si Aleš Kapica myslí, že u overlayfs by to určitě fungovalo.

Proto také ignoruji trekkerovy a Kubečkovy výzvy abych dohledával věci, které momentálně stojí zcela mimo moji pozornost.

Ještě že je na co se vymluvit...

[Aleš Kapica]

Že to nefunuje? Ale jděte. Zrovna začlenění Btrfs bylo pro mne doslova požehnání. A rozhodně nemám pocit, že by tím jeho vývoj nějak utrpěl - právě naopak. V podstatě je to jediný souborový systém, který svými možnostmi tvoří na linuxu protiváhu k ZFS.

A pokud si něco Aleš Kapica myslí, tak to taky dříve nebo později bude. Prozatím se mi nestalo, že bych v oblasti IT někdy vsadil na špatného koně.

[trekker.dk]

Zrovna začlenění Btrfs bylo pro mne doslova požehnání.

Nesouvisí s rychlostí vývoje v mainline a mimo.

A rozhodně nemám pocit, že by tím jeho vývoj nějak utrpěl - právě naopak.

AFAIK vývojáři jádra měli pocit opačný. A pokud říkáte, že nemáte čas sledovat vývoj jádra, tak oni ho IMO mají.

V podstatě je to jediný souborový systém, který svými možnostmi tvoří na linuxu protiváhu k ZFS.

Taktéž nesouvisí s rychlostí vývoje v mainline a mimo.

A pokud si něco Aleš Kapica myslí, tak to taky dříve nebo později bude. Prozatím se mi nestalo, že bych v oblasti IT někdy vsadil na špatného koně.

Ehm, Reiser4? Navíc jste stále mimo téma, nejde o žádné koně, ale o to, že začlenění do mainline projektům většinou nepomáhá k urychlení vývoje.

[Aleš Kapica]

V době, kdy jsem používal Reiser4 vývoj Btrfs teprve začal, takže nemyslím, že bych jeho používáním nějak šlápnul vedle. Btrfs sebou přinesl nové možnosti a je zcela přirozené, že koncepce klasických souborových systémů již zastarala.

Pokud jde o vývojáře jádra, tak je vcelku logické aby dění kolem kódu sledovali. Jenže mě na rozdíl od nich, nebo některých mých kolegů, vývoj který bezprostředně souvisí s kernelem neživí. Takže není divu, že mi unikl i důvod proč sešlo z původně oznámeného začlenění overlayfs.

Evidentně však ten důvod unikl i vám, jinak byste uvedl odkaz na konkrétní s tématem související vlákno, místo toho otírání o mou osobu, jimž plevelíte tuhle diskuzi.

[Michal Kubeček]

Evidentně však ten důvod unikl i vám

Na to, že mu - podle vás - unikl, ho popsal dost přesně. Přinejmenším podstatně přesněji než vy…

[Aleš Kapica]

Jo? A kde? Nějak jsem si nevšimnul. Jediný link k věci byl od vás, jenže z doby kdy o jádře 3.10 ještě nebylo potuchy.

[Michal Kubeček]

Nějak jsem si nevšimnul.

Očividně. Já ale ano.

Jediný link k věci byl od vás, jenže z doby kdy o jádře 3.10 ještě nebylo potuchy.

Byl to poslední (nejnovější) submit, který jsem našel. Pokud vy víte o nějakém novějším, očekávám, že se podělíte o odkaz. A mimochodem, pokud by byla tato série přijata, objevila by se v mainline právě ve verzi 3.10 (nebo, chcete-li, 3.10-rc1), takže je mi záhadou, z čeho vychází vaše tvrzení, že tehdy "o jádře 3.10 ještě nebylo potuchy").

[trekker.dk]

V době, kdy jsem používal Reiser4 vývoj Btrfs teprve začal, takže nemyslím, že bych jeho používáním nějak šlápnul vedle.

Opravdu nedokážete udržet myšlenku přes 2 příspěvky? Psal jste o sázení na špatného koně. Vzhledem k tomu, jak Reiser4 dopadl (nijak), vám ho jako dobrého koně těžko někdo uzná.

Pokud jde o vývojáře jádra, tak je vcelku logické aby dění kolem kódu sledovali. Jenže mě na rozdíl od nich, nebo některých mých kolegů, vývoj který bezprostředně souvisí s kernelem neživí.

Přesto tady ale dáváte fundované názory na to, proč začleněn nebyl.

Evidentně však ten důvod unikl i vám, jinak byste uvedl odkaz na konkrétní s tématem související vlákno, místo toho otírání o mou osobu, jimž plevelíte tuhle diskuzi.

Zajímavé, když vy něco tvrdíte, ale neuvedete příklad a nedáte link, je to v pořádku, protože "nesledujete dění okolo jádra". Když ho neuvedu já - protože je to hledání na půl minuty, což byste měl zvládnout - je to otírání o osoby a plevelení diskuze...

LMGTFY: http://lwn.net/Articles/600106/ , třeba

Dovolil bych si ocitovat první odstavec

Whiteout is now a special char device instead of a symlink, this breaks compatibility with previous versions. See attached conversion script (takes upperdir as argument).

To mi opravdu nepřijde jako kód vhodný pro začlenění do mainline. Pokud nebudete chtít jenom plácat do vody, můžete si před další diskuzí dohledat reakce na ten mail, ze kterých je docela dobře vidět, že se ten kód pořád vyvíjí...

[Aleš Kapica]

Chápu, že taková změna může být nepříjemná z hlediska aplikací, které hrabou do překrytého prostoru, nicméně pro to, jakým způsobem se (alespoň tedy u nás) overlay používá, nejde o změnu nijak zásadní.

[trekker.dk]

Jestli pro vás (nebo obecně pro některé uživatele) ta změna není zásadní, není pro mainline relevantní. Vzato velice obecně tahle změna znamená (kdyby overlayfs bylo v mainline), že po update jádra lidem něco přestane fungovat. To je stav, který se v hlavní řadě považuje za problematický.

Takže to fakt není o iluminátech, velkých korporacích a **** - je to o stavu a stabilitě (z pohledu změn, nikoliv pádů) kódu.

[ebik]

Pro vás sice ne, ale brzy by se našlo dost lidí, kteří by nějakou podobnou věc z takto vyvíjeného kódu použili (a ani by nevědeli jak, protože by používali nějakou utilitu) a divili by se, že se jim to při upgrade kernelu rozbilo. Ne takhle se kód v mainline nechová. Takhle se chová kód, který je vydaný třetí stranou a není tedy problém buď přikompilovat modul nebo překompilovat patchnuté jádro, zároveň s instalací nové verze utility. Každý pak ví, který patch funguje se kterou utilitou a ani v patchi a ani v utilitě není potřeba řešit zpětnou, nebo dopřednou kompatibilitu.

[Aleš Kapica]

Víte k čemu je ten whiteout?

[ebik]

Ano, a dovedu si představit nástroj, který vytvoří offline tu část, která se pak přimountuje jako ten overlay. Třeba bude mít někdo CDROM image a bude chtít spustit systém, který už od přimountování má některé soubory vymazané. Tak si na to napíše utilitu, která vytvoří tu overlay image bez overlayfs a pak to smountuje dohromady.

[Aleš Kapica]

Četl jsem te odstavec několikrát po sobě, ale nejsem si jist, zda jsem to pochopil správně. Takže se alespoň pokusím o rekapitulaci.

Někdo má na CD nějaký systém a chce ho namountovat tak, aby některé soubory, které na něm jinak existují v namountovaném adresáři vidět nebyly? Resp. byly vidět pouze za splnění určitých podmínek?

No. Ano. To si sice představit dovedu, jen nechápu k čemu by to bylo dobré. Překrytá vrstva je pro nás zajímavá spíš z opačného důvodu. Ale budiž. V zásadě v tom nevidím problém, protože podle verze jádra lze detekovat, jakým způsobem se to má udělat. Ostatně, mám-li mít skript, který funguje nějak rozumně, tak bohužel díky tomu, že není oficiální součástí kernelu ani jedno řešení (ať již aufs, nebo overlayfs) musím stejně ošetřit několik různých metod řešení whiteout souborů.

Podle toho co vím je i jiný možný způsob řešení problému - přes atributy, jenže je zde problém se souborovými systémy, které s nimi pracovat neumí. Proto se hledá nějaké obecně použitelné řešení. Z praktického hlediska je to však zcela parciální problém.

[trekker.dk]

Překrytá vrstva je pro nás zajímavá spíš z opačného důvodu.

Pro vás. Jenže někdo jiný může mít jiné potřeby mezi které patří možnost plně využívat overlay jako standardní filesystém. A standardní filesystém musí mít možnost mazat soubory.

Proto se hledá nějaké obecně použitelné řešení. Z praktického hlediska je to však zcela parciální problém.

... jehož řešení nicméně zjevně není triviální.

[trekker.dk]

To přece vůbec není důležité - důležité je to, že se nekompatibilně mění způsob, jakým je implementován. To je prostě pro kód na úrovni mainline nepřípustné.

[Aleš Kapica]

Řekl bych, že k této změně bylo přikročeno právě proto, aby se vyšlo vstříc rozmarům vývojářů jádra, neboť jak už jsem uvedl o kousek výše, z praktického hlediska použití overlaye je šumafuk co se použije.

[trekker.dk]

No, osobně bych odhadl, že vývojáři jádra budou mít trochu větší rozhled než vy, takže s výrazy typu "rozmarům" bych, být vámi, byl opatrný. To, že vám je něco šumafuk, ještě neznamená, že je to - z dobrých důvodů - šumafuk i člověku s dobrou znalostí problematiky. Nebo ještě jinak - pro vaše využití overlayfs jsou některé věci možná irelevantní, fajn. Bylo by ale dobré uvědomit si, že jádro se nepíše (jen) pro vás.

[Michal Kubeček]

Řekl bych, že k této změně bylo přikročeno právě proto, aby se vyšlo vstříc rozmarům vývojářů jádra

Na základě čeho byste to řekl? Na základě svých hlubokých znalostí VFS? Tak hlubokých, že aniž byste sledoval tu komunikaci (což jste sám přiznal), okamžitě poznáte, jestli je vhodnější řešení Miklose Szerediho nebo Al Vira?

[Aleš Kapica]

Už několikrát jsem naznačil, že mám kolem sebe lidí co jsou ohledně kernelu a jeho vývoje mnohem víc v obraze nežli já, protože se přímo podílejí na jeho vývoji. Z tohoto úhlu pohledu jsem pouhý uživatel toho co nabízí mainline. A tohle vlákno začalo tím, že jsem učinil připomínku k faktu, že doposud do jádra nebylo integrováno ani jedno řešení, kterým by bylo možné overlay realizovat. Toť vše.

Nicméně, jak je zřejmé z posledního relevantniho příspěvku v tomto vlakně, snad od verze 3.18 konečně něco k dispozici bude. Jak se říká: slibem neuraziš. Takže nezbývá než doufat, že někomu něco neprelitne přes nos do té míry, že bude Szeredi muset overlayfs znova prekopat a ze začlenění nebude opět nic.

[Michal Kubeček]

Na to bych tak úplně nespoléhal, je to dost na poslední chvíli (3.17 vyjde s největší pravděpodobností o víkendu). Ale hlavně jde o to, abyste pochopil, že to, co se děje, je normální technická diskuse a přirozený vývoj, ne vrtošivé rozmary někoho (koho označujete hvězdičkami), kdo si postavil hlavu, protože toho druhého nemá rád nebo od něj nedostal úplatek. Jenže k tomu by bylo potřeba, abyste se do těch threadů konečně aspoň zběžně podíval. Pokud budete vycházet ze svých mlhavých dojmů podložených jen zprávami agentury JPP, budete nadále šířit absurdní konspirační teorie. Volba je na vás…

[Aleš Kapica]

Ale hlavně jde o to, abyste pochopil, že to, co se děje, je normální technická diskuse a přirozený vývoj, ne vrtošivé rozmary někoho (koho označujete hvězdičkami), kdo si postavil hlavu, protože toho druhého nemá rád nebo od něj nedostal úplatek.

Tak zrovna o tomhle mám silné pochybnosti.

[Michal Kubeček]

Všiml jsem si. Ale zkuste si přečíst i ty další dvě věty.

[Aleš Kapica]

A vy si pro změnu zase zkuste přečíst vlákno na které odkazoval Drom. Pak se můžeme bavit o čistě technické diskuzi.

[Michal Kubeček]

Jediný netechnický mail, který tam vidím, je ten od Woody Suwalskiho a ten se zrovna dost silně podobá vašim komentářům, takže ho těžko můžu považovat za příklad odmítání overlayfs z netechnických důvodů. Takže mi poněkud uniká, na co narážíte.

[Aleš Kapica]

Já teda nevím jak to vnímáte vy, ale já bych shrnul zhruba takto:

Szeredi poslal patch se žádostí o začlenění. To už tu bylo a mělo to stejný scénář jako nyní, proto ta Woodyho ironie, který je na tom evidentně jako já.

Howells k tomu jen napsal že to testoval. Načež jako čertík z krabičky vyskočil Okajima se svými technickými připomínkami. Logicky, protože je autorem podobného řešení, které má ovšem být z hlediska kódu mnohem větší čuňačina. Osobně to nejsem schopen posoudit, protože se v kódu nehrabu a z mého pohledu je naprosto jedno zdali bude začleněn aufs, overlayfs, nebo oba moduly.

Na to mu Szeredi odpověděl, s tím že co si pamatuje, tak aufs aby mohlo fungovat, některé věci z mainlainu odstraňovalo. Ale že je ochoten mu případně pomoci některé z těch věcí řešit. Načež Okajima začne dokazovat že tomu tak dávno není, jeho kód je stejně dobrý jako od Szerediho a má-li být začleněn overlayfs, tak že v takovém případě by měl být začleněn i jeho kód. (To není citace, ale shrnutí jeho reakce)

Takže to nejspíš dopadne jako posledně. Aby ho nenasrali, tak nezačlení vývojáři mainline pro jistotu nic a uživatelé jako já, nebo Woody opět ostrouhají. A takhle si technickou diskuzi vskutku nepředstavuji.

[Michal Kubeček]

To je ovšem velmi svérázná (dez)interpretace.

Načež jako čertík z krabičky vyskočil Okajima se svými technickými připomínkami.

Takže ty připomínky nakonec jsou technické (i podle vás). To jsou mi věci… Nemluvě o tom, že Okajima není maintainerem příslušného subsystému, takže jeho výhrady vůbec nemusejí být důvodem k odmítnutí.

Ale jak už jsem řekl, mnohem větší problém vidím v tom, že do vydání 3.17 zbývá jen pár dnů.

[Aleš Kapica]

Co vím, tak podobným způsobem proběhla komunikace i při pokusu o začlenění u jádra 3.10 a celá věc i podobně skončila - žádné konkrétní důvody proč k začlenění nedošlo nikde nepadly. Jediný rozdíl byl v tom, že se tehdy do toho začala angažovat jedna osoba, která přišla s tím že by to mělo být ještě úplně jinak. Jenže vyšuměla dřív, než stihla říct někomu jak. Pochopitelně od jádra 3.10 se vývoj hnul zase o kus dál, což si nespíš vynutilo změny i u overlayfs, takže proto nový patch.

Okajima sice není maintainerem, ale má "technické připomínky". Takže důsledkem bude, že celá věc opět bude odložena s tím, že overlayfs je problematický kód, který je třeba ještě doladit.

A pokud jde o pečlivost čtení. Szeredi hned v prvním mailu píše, že by chtěl kód začlenit do řady 3.18, takže mi uniká spojitost s vydáním stable verze jádra 3.17.

[Michal Kubeček]

Co vím, tak…

Raději si konečně přečtěte ty thready, ať můžete operovat něčím, co opravdu víte. A už jsem se ptal jednou: vy se opravdu cítíte tak kovaný ve VFS a filesystémech, abyste si troufal posoudit, které technické připomínky jsou relevantní "konkrétní" a které jsou jen pokusem o zdržování? (Kromě toho, že je mi záhadou, co by to zdržování komu vlastně přineslo.)

A pokud jde o pečlivost čtení. Szeredi hned v prvním mailu píše, že by chtěl kód začlenit do řady 3.18, takže mi uniká spojitost s vydáním stable verze jádra 3.17.

Asi to bylo naivní, ale doufal jsem, že bavíme-li se v diskusi pod Jadernými novinami, budou mít všichni zúčastnění aspoň základní představu, jak vývojový cyklus funguje. A bude jim tedy jasné, že aby se kód implementující novou funkci (přesněji cokoli, co není jen oprava chyby) dostal do 3.18, je potřeba, aby byl přijat do příslušného subsystému před začátkem příslušného merge window, tj. před vydáním 3.17 (přičemž čím dříve, tím lépe). Teoreticky je sice možné, že by to prošlo i po jeho začátku, ale bylo by to hodně neobvyklé a Linux takové věci nevidí rád (velmi mírně řečeno).

[trekker.dk]

Na to mu Szeredi odpověděl, s tím že co si pamatuje, tak aufs aby mohlo fungovat, některé věci z mainlainu odstraňovalo.

Jste si jistý, že jste si tu diskuzi přečetl pořádně?

[Michal Kubeček]

Problém bych neviděl v pečlivosti čtení, ale spíš v tom, že si názor udělal už (dávno) před jejím přečtením.

[petr_p]

Prý Ubuntu také vyhodí Aufs z jádra, protože v Dockeru přejde na device mapper.

[Conscript89]

+1, nad tim si povzdechnu prakticky kazdy druhy den. Jednou ten FS mozna napisu :D

[Drom]

https://lkml.org/lkml/2014/9/29/350

[frr]

A pak se pokoušejte něčím přispět do kernelu...

[Michal Kubeček]

Pokouší se o to spousta lidí a jak lze snadno nahlédnout v gitu, docela často i úspěšně. Jen to chce rozumět tomu, jak věci fungují a nebrat každou připomínku jako akt vyhlášení osobní války.

Jistě, někdy je frustrující, když třeba posíláte čtvrtou verzi patche kvůli coding style a pořád ještě nikdo nenapsal, jestli je tohle vůbec správný způsob, jak problém řešit. Ale stačí pár zkušeností s hledáním a opravováním problémů ve zdrojácích projektů (i výrazně menších), které takhle přísnou "štábní kulturu" nemají, aby člověk pochopil, že to není samoúčelné.

[frr]

Tak nějaké menší sousto jistě projde snáz - one-liner updaty apod. Ne že bych se osobně o něco takového někdy vážně pokusil - asi dvakrát jsem nějaký one-liner poslal a stačilo mi ke spokojenosti, že to lidi najdou googlem v LKML, když už se nikdo nenamáhal to zařadit. Spíš jsem v tomto případě reagoval na ten odkaz = debatu, kterou tvoří mix technického deliria (sada dvě stě patchů) a hašteření dvou autorů konkurenčních projektů na hraně osobní rozmíšky...

[Michal Kubeček]

asi dvakrát jsem nějaký one-liner poslal a stačilo mi ke spokojenosti, že to lidi najdou googlem v LKML, když už se nikdo nenamáhal to zařadit

Málokdy stačí jen LKML (pokud vůbec u něčeho). Je potřeba si přečíst Documentation/SubmittingPatches a podívat se do MAINTAINERS (nebo rovnou použít scripts/get_maintainer.pl). Když se to pošle správným adresátům, bývá reakce hodně rychlá.

mix technického deliria (sada dvě stě patchů)

Já jich ve větvi overlayfs.current vidím patnáct.

[Bystroushaak]

Moje schránka doručené pošty vypadá, jako by vlak naboural přepravující e-maily a pak se na něj ještě zřítilo letadlo s nákladem e-mailů.

nemělo by to být spíš

Moje schránka doručené pošty vypadá, jako by naboural vlak přepravující e-maily a pak se na něj ještě zřítilo letadlo s nákladem e-mailů.

?

[Yontalcar]

Podle originálu spíš

Moje schránka doručené pošty vypadá, jako by vlak přepravující e-maily naboural do jiného vlaku přepravujícího emaily a pak se na něj ještě zřítilo letadlo s nákladem e-mailů.

[trekker.dk]

Přesně tak, tenhle překlad se moc nepovedl.

[Michal Kubeček]

Tohle taky moc ne:

většina jádra na téhle úrovni pracuje s pamětí pomocí stránky struktury

Dokud jsem si to otrocky slovo od slova nepřeložil zpátky, vůbec jsem netušil, co by mohla být ta "stránka struktury" (hint: je-li něco v originále "psacím strojem", je to obvykle kód a ten je lepší nepřekládat).

[Michal Kubeček]

A o kousek dále:

To například vylučuje nulové kopírování vstupně-výstupních síťových operací se souborem uloženým v zařízení NVM.

[Václav "Darm" Novák]

Nepomáhal s tím Fry?