Jaderné noviny – 29. 10. 2014: Seznam přání pro jádro pro stolní počítače (diskuse)

[Jendа]

ale pak po určitém čase zapíše obsah paměti na disk (přímo z firmwaru)

To je blbý, to určitě nepůjde šifrovat, že? Konečně jsme se dostali do stavu, že na uspaný notebook nejde provést coldboot, a oni to výrobci hned zkazí.

Lépe implementovat v HW jenom alarm, který po uplynutí toho intervalu systém probudí, a systém se zapíše do (šifrovaného) swapu sám.

Proč vůbec takovou věc dávat do firmware?

Otázky systému souborů

Uvítal bych FS-level verzování. Něco jako kdyby se vytvořil snapshot po každém zápisu souboru do určených adresářů. Už jsem si říkal, že si snad něco takového napíšu v userspace… Občas se mi stane, že něco omylem přepíšu, smažu atd.

[Heron]

Uvítal bych FS-level verzování. Něco jako kdyby se vytvořil snapshot po každém zápisu souboru do určených adresářů. Už jsem si říkal, že si snad něco takového napíšu v userspace… Občas se mi stane, že něco omylem přepíšu, smažu atd.

HAMMER?

Jinak i na obyč BTRFS by šlo dělat snapshoty třeba každou minutu. Není s tím nejmenší problém. Nápad: Při vhodné kombinaci se subvolume find-new by také šel získat seznam změněných souborů. (Jen nápad, nemám vyzkoušeno.)

[Jendа]

HAMMER?

Bohužel jsem vendor-locknutý na Linux.

Jinak i na obyč BTRFS by šlo dělat snapshoty třeba každou minutu.

Tomu jsem se chtěl vyhnout… Školní ZFS na větším množství snapshotů naprosto selhává.

root@archer:~# time zfs list -t snap|wc -l
2608

real	0m53.583s
user	0m0.212s
sys	0m2.860s

Navíc já to chci hned. Takže snapshot každou sekundu?

[Heron]

Btrfs není zfs (což platí i naopak), zde jsou snapshoty, stejně jako subvolume pro userspace k nerozeznání od adresářů a výpis adresářů je tak rychlý, jak rychle se stihne načíst adresářový záznam z disku. Než jsem se uklidnil, měl jsem přes 10 tisíc snapshotů 7 různých subvolumes a pohoda.

Jinak by mě docela zajímalo, k čem tuhle funkcionalitu požaduješ, když i jednou za minutu je málo. Pokud pominu, že každý editor nebo obecně programy umí funkci redo případně něco na ten způsob tak i kdyby ne, vrátit se o minutu zpět a třeba to udělat znovu, není takový problém. Ale rád se dozvím víc.

[Jendа]

Stává se mi, že pomocí mv, cp nebo > znova přepíšu soubor, který jsem před chvílí vytvořil. Nebo něco funguje, udělám změny, a pak to nefunguje, a chtěl bych si zobrazit diff. Realtime to chci proto, že udělat :wq, gcc, ./foo > sou<tab>bor.c, kurva zvládnu pod minutu.

10 tisíc snapshotů 7 různých subvolumes je pár dní při snapshotování každou minutu.

[Heron]

Mno, ehm git?

Nehledě na to, že stopro bude existovat plugin do vimu, který bude zachovávat historii úprav i přes několik spuštění, nebo stačí prostě jen změnit způsob práce na :w a ve druhém terminálu (druhém tabu screenu, split screen apod.) pokračovat gcc atd.

Na tohle buď zabere FS který bude snap opravdu po každém fsync (hammer), nebo vlastní udělátko na bázi inotify.

[Jendа]

Mno, ehm git?

Fakt nedělám commit po každé úpravě.

nebo vlastní udělátko na bázi inotify

Přesně takhle jsem to chtěl implementovat.

[koudy]

A co to dělat teda celé z vimu?

:w, :!gcc, :!./foo > soubor.c

Navíc to budete to mít v historii.

Ještě jednodušší by bylo udělat si makefile, protože vim umí skákat po chybách.

Úplně nejjednodušší mi přijde otevřít si 2 terminály, jak již navrhuje kolega níže/výše/někde. :)

 

(neberte to příliš vážně, bo VMS končí)

Pořiďte si VMS..., ten má tuto vlastnost implementovanou dosti geniálně (každá změna souboru se zapíše jako nová verze souboru, která se píše/psala jako jmeno.souboru;#verze )

[Heron]

:w, :!gcc, :!./foo > soubor.c

Přiznám se, že i když o této možnosti vím, tak jsem se to nikdy nenaučil dostatečně efektivně využívat. Naopak využívám screen a přeskakování mezi "taby" po každém :w. Za vrcholný úspěch ve vimu považuji namapování vlastních akcí na Fx klávesy, kam by se dal umístit i onen :w a !git něco (nebo při dostatečném šílenství i !btrfs sub snap ....

[koudy]

Jj souhlas, není to na běžnou práci.

To bylo spíše "jaké další možnosti máte" než že bych čekal že se tím budete řídit :)

Namapování kláves není špatný nápad, to si budu muset taky nastavit, díky za radu :)

Ještě že je vimrc, to mám asi 3x zazálohované, protože bych to zas dával půl roku do kupy...

Ten ":make" je docela šikovná věc, na menší projekty doporučuju.

Screen moc nepoužívám zase já, i když na jednoduché porovnání není nic lepšího.

[Jendа]

Pořiďte si VMS..., ten má tuto vlastnost implementovanou dosti geniálně (každá změna souboru se zapíše jako nová verze souboru, která se píše/psala jako jmeno.souboru;#verze )

Ano, přesně takhle to má vypadat (a přesně takhle jsem se to dočetl v UNIX Hater's Handbook z roku 1990). Žádné generování FS-wide snapshotů v době, kdy se třeba nic nezměnilo…

[Heron]

Jenomže ono každé pro má své proti. Kdyby se po každé změně (asi tedy po každém fsync souboru) vytvořila nová verze, tak by jsi měl cca 100 verzí souborů za 1s. (Dejme tomu o binárních logů databázových systémů či journalů já nevím třeba sqlite). To by asi nešlo,co.

Takže by se musel vytvořit systém na označení, které soubory chci a které nechci verzovat. Nastala by dlouhá diskuse, zda má být default verzování zapnuté či vypnuté. (Kdyby to bylo default zapnuté, přišlo by se o výkon, kdyby to bylo vypnuté, lidé by nadávali, že to zapomínají zapnout.)

Dále by musel být systém na odstraňování starých verzí. Bez něj by dříve nebo později na daném FS došlo místo. A opět by se našli kritici tohoto systému, protože jim automaticky smazal verze, které hrozně potřebují.

Atd.

Přijde mi lepší mít k diposici komponenty, se kterými si totéž mohu zrealizovat. Těch tříd komponent je více, na každou činnost se hodí jiná. Na něco zrovna ten git, na něco jiného třeba btrfs snap na něco ještě dalšího třeba inotify a triggrovat si akci dle potřeby.

[koudy]

Ten FS na VMS byl především na textové soubory - každý řádek souboru se ukládal zvlášť a ještě navíc bez znaku nový řádek.

 

Nešlo by udělat něco jako příznak "?změnil se soubor?" a podle toho ne/od-zálohovat soubor?

V ideálním případě by se to propagovalo do nadřazených adresářů.

Tím by se asi dost snížilo zatížení disku. (teď tady jen tak házím myšlenkama, určitě se nad tím někdo zamyslel líp a je to vyřešený rozumnějc než to navrhuju já)

 

Nebyla by hloupost dávat žurnál na takovýto disk? Nebo téměř cokoli co se rychle mění - dát tam DB je už úplně asi mimo ne? (sqllite neberu jako DB)

Rozuměl bych podobný FS například na HOME adresářích, nějaké sdílené adresáře a třeba i /etc a www stránky, ale na jiná použití?

[Heron]

Nebyla by hloupost dávat žurnál na takovýto disk? Nebo téměř cokoli co se rychle mění - dát tam DB je už úplně asi mimo ne? (sqllite neberu jako DB)

Byla. Jenže doba, kdy každý OS měl jen v minimálním základu 8 FS (ne-připojené s různými volbami jako ro, noexec apod.) je zdá se dávno pryč. To byla také doba, kdy si databáze sami spravovaly vlastní blokové zařízení a neběžely nad FS. Jenže ta doba je pryč. Pro něco je to špatně, pro něco je to dobře. Mě se sjednocování různých částí adresářového stromu pod jeden FS obecně nelíbí, protože ten proces je někdy dělán dost živelně. (Jako že když máte oddělený /usr tak třeba nenabootujete, protože autor jistého initu nepovažuje oddělený usr za dobrý nápad a proto ho všem zakáže.)

Rozuměl bych podobný FS například na HOME adresářích, nějaké sdílené adresáře a třeba i /etc a www stránky, ale na jiná použití?

Vzhledem k tomu, že kde co dneska používá služeb souborových databází (a nikoliv třeba systémové databáze třeba na vlastním blokovém zařízení), tak ona potíž se 100 verzemi za 1s vám klidně vznikne i na /home. Je ve FF je 16 sqlite databází i se svým žurnálem.

[XX]

Staci si uvedomit, ze snapshot z 13:57:42 z minuleho patku nepotrebujes. Chci tim rict, ze je dobre mit caste snapshoty pro nova data a jak starnou, tak je redit. Neco jako:

1 minutove 1..5

10 minutove 1..5

1 hodinove 1..x

1 denni 1..y

(tydenni, mesicni..)

Tj. potreboval bys 5+5+x+y snapshotu, coz tak moc neni, ale je to jen ukazka.

Je to vic skriptovani, ale vyplati se. Neco podobne nam beha v praci pres rsync, cele to pousti cron:

Denne: posledny denni (y) se maze.

Kazdou hod: posledny 1hodinovy (x) se maze, ale jednou denne rotuje na prvni denni (1).

Kazdych 10min: posledny 10minutovy (5) se maze, ale kazdnou hodinu rotuje na prvni 1hod (1).

Kazdou minutu: poridis novy snapshot, a posledny 1minutovy (5) se maze, ale kazdych 10min rotuje na prvni 10min(1).

Snad jsem to moc nezkomplikoval.

Predstavivosti se meze nekladou.

[ncweohfnow]

Nerad Vam kazim skumanie ako vymysliet nove koleso, ale s radostou pouzivam nilfs (https://en.wikipedia.org/wiki/NILFS) uz dlhsiu dobu pre uctovnisky SW. Clovek nikdy nevie, ktoru sekundu mu zacne nejaky windows cervik sifrovat data na disku a podobne. Spomenuty FS riesi "snapshootovanie" po kazdom zapise na disk. Mal som potrebu zatial iba raz zachranit zmazany subor a bola to otazka 10 minut citania a 2 minuty pisania. Pekne.

PS: Spomenuty FS pouzivam IBA na particii s 5 GB datami na oddieli cca 10 GB, kde je uctovnicky SW, par naskenovanych dokumentova a podobne somariny, ktore sa pouzivaju vyhradne z windows PC, pristupne cez sambu (a pripadne z virtualu). Nemyslim, ze by spomenuty FS bol vhodny na 2TB zbierku dat...

[ed]

myslim, ze v tomto ohlade mlatite uplne nespravneho slameneho panaka a problem existuje medzi klavesnicou a stolickou.

bez zavedenia dodatocneho API nema filesystem ako poznat, ze (automaticky) vytvoreny snapshot suboru je nejakym psosobom vnutorne konzistentny. iste mozno namietat, ze ak sa zavre popisovac, aplikacia so suborom skoncila, lenze linux na rozdiel od widiel neforcuje ziadne zamky, takze na jeden subor moze byt otvorenych niekolko popisovacov naraz a mozu existovat cinnosti pri ktorych aplikacia popisovac uzavrie aj medzi zapismi, kedy subor necha v (pre aplikaciu) inkonzistentnom stave.

to je mimo ine aj dovod, preco (aspon pokial som sledoval) filesystemy neskusaju nejako agresivne zurnalovat samotne data. jednak to chce strasne velky priestor v zurnale a za druhe (co je dolezitejsie) je to vacsinou zbytocne, pretoze v pripade padu to aj tak konzistenciu dat nejako dramaticky nezlepsi (minimalne nie dost na to, aby sa oplatilo plytvat na zurnalovanie dat vykonom bez dodatocneho API).

[anonym]

presne vim na cem to ti bezi, a takovemuhle "vykonu" bych se nedivil (hint: beta)

pro vypis se prochazi spojak (vytvoreni rovnou vrazi novy prvek na zacatek, takze no problem), ktery je rozesety v malych blocich po vsech diskach (v tvem pripade hlavne po tretine, protoze to vzdycky je mensi jak 1 blok, a raidz2 k tomu prida 2 pro paritu, takze mas celkem 3 bloky, coz deli tvuj pocet disku).

ZFS je optimalizovane na to aby se snapshoty primarne vytvarely v O(1), sekundarne mazaly v O(1) (plus minus, najit snapshot je porad O(n) vuci poctu snapshotu na datasetu). vypis vsech snapshotu podle nich neni uplne casta operace

[Jendа]

(hint: beta)

iftop si myslí, že to brzdí seeky, ne linka. A tam si polem nepomůžeš… Odpovídá to nějakým 50 seekům za sekundu, což je běžná rychlost 7k2 disku.

[anonym]

nemluvil sem o lince ale spis o tom radici toho 'pole' (linka ti bude vadit pri scrub/resilver)

bohuzel nemam zadny takhle velky system s direct-attached disky, abych to vyzkousel, ale v teorii by to melo jit #seeku na disk * #disku

ale obecne ano, vypis snapshotu v ZFS je random IO-heavy operace, vytvareni (a mazani, jakmile si ho nasel) neni

[petr_p]

Uvítal bych FS-level verzování.

Nemůžu si s úšklebkem nevzpomenout na v článku zesměšňovaný VMS :D

[Michal Kubeček]

Neodpustím si tradiční WtF-list:

"Stolní počítače"??? Opravdu je nezbytné vymýšlet krkolomné české verze úplně všech zavedených pojmů? Nemluvě o nekonzistenci, protože později už desktop (z hlediska kontextu IMHO mnohem vhodněji) překládáte jako pracovní plochu nebo prostředí.

„přání pro instalatéry“ adresované vývojářům jádra Kayi Sieversovi, Lennartu Poetteringovi a Haraldu Hoyerovi.

Je tam "by", takže ti tři jsou autoři, ne adresáti, a ta jména tedy nemají být ve třetím pádu ale v sedmém.

[Tadeáš Pelech]

Stolní počítače je normální výraz, nevymyslel jsem si ho já, ale v tomto konkrétním kontextu se opravdu nehodí.
Díky za obě upozornění, upraveno.

[Filip Jirsák]

Mě tedy nejvíc zaujal pomocník uživatelský a procesy mimo paměť:

pomocníka uživatelského pro ukončování procesů mimo paměť (OOM)

Co takhle "pomocníka v uživatelském prostoru pro ukončování procesů při nedostatku paměti"?

[lertimir]

Je zajímavé, že mezi požadavky není prioritizace procesů, které patří oknu s fokusem oproti backgroundu. Pro reakci systému by to mohlo mít pozitivní vliv.

[Jendа]

To snad není věc kernelu. Stačí, aby window manager nastavoval nice.

Bohužel v dnešní době na desktopu není bottleneck CPU ale I/O a v tom Linux naprosto selhává (zejména kvůli mizerně implementované cache) a žádný nice/ionice tomu nepomůže.

[lertimir]

Asi máš pravdu, ale možná analýzy k tomu, jestli by pro desktopy nebyl vhodný jiný scheduler, by mohly být. Přece jen shedulery jsou prostavené spíše pro serverové zátěžě. A optimalizace pro I/O je samozřejmě další závažna otázka.

[Nicky726]

To snad ale existuje, plánovač vyvíjený speciálně pro desktop užití: BFS.

[Jendа]

Já teda potkával hlavně ten problém, že když jsem dal kopírovat velký soubor, tak mi to vylilo cache všech ostatních aplikací…

[lertimir]

Já potkávám 2-3 typické problémy.

1. Kopirování velkých souborů na pomalejší zařízení blokuje celý stroj. I přes výrazné snížení parametru podle jaderných novin se to pořád někdy kouše.
2. Snížení response systému při dávkových zpracováních fotek v desktopu. Např. po doladění RAW operací zpracování 200 fotek z RAW do jpg/png
3. Podobně jako 2 překodování nebo jiné zpracování videa v backgroundu.

V žádném z těchto případů třeba nejde efektivně si pustit vedle toho video a mít ho bez lagů, nebo třeba pracovat v digikamu v foregroundu a mít ho výkonný. (na 4jádru i5 na 3,8GHz)

Považoval bych za rozumné, když by na desktopu bylo možné systém nastavit tak, aby front aplikace (okno s fokusem) měla vše, co potřebuje, a ostatní nesystémové aplikace (samozřejmě systémové aplikace jako operace se swapem, ntp server ap. by byly ještě prioritnější), aby dostaly zdroje až když je front aplikace nepotřebuje. (alespoň v praktickém slova smyslu "vše", např., když zdroj potřebuje jak front aplikace, tak něco běžící v pozadí, tak to "vše" neznamená nekonečno:0, ale řekněme 98:2 nebo 95:5, ale také ne 50:50, jak je to často teď. A také tím nemyslím, že CFQ nebo jiné rovnoprávné postupy by se měly rušit, jen to, že možnosti silné prioritizatice procesu v popředí nejsou.

[Heron]

V žádném z těchto případů třeba nejde efektivně si pustit vedle toho video a mít ho bez lagů, nebo třeba pracovat v digikamu v foregroundu a mít ho výkonný.

Toto tedy nepozoruji. Konvertoval jsem 290 GB videí do menšího rozlišení (hlavně pro menší objem pro mobilní zařízení) v HandBrake, nacpal jsem frontu, nastavil minimální prio (nice 19) a normálně pokračoval v práci včetně přehrávání kde čeho a hraní minecraftu. Kdybych neslyšel ventilátor ve zdroji tak ani nevím, že počítač něco dělá. (AMD FX 8350)

(Potom jsem teda usoudil, že video vlastně ani nepotřebuju a vytáhl jsem z toho jen zvuk a ten převedl do schůdnějšího formátu pro starý hloupý nokia mobil. Opět, hromada ffmpegů, nice 19 a věnoval jsem se něčemu jinému.)

[lertimir]

To asi máš pravdu. Jednoduchý úkon realizovaný třeba ffmpeg s nastaveným nice je OK. To co OK není, je když máš třeba 50 záběrů, mezi nimi máš v kdenlive nastavené nějaké přechody, nebo navíc vyrobené animace třeba v blenderu, vše je v podstatě video ve formátu několika konkrétních kamer, většina ve fullHD a pár záběrů třeba v nižším rozlišením, ty máš nadefinované, střihy, přechody a animace, specifikuješ výstupní formát a v tom kdenlive to pustíš. A víš, že ta hodina filmu bude 3 hodiny výpočtů, ale to co vadí, že ty 3 hodiny je počítač těžce použitelný. Když bych mohl normálně pracovat (nebo se třeba bavit), a zpozdil se výpočet na 4 hodiny tak OK.

Je možné, že hlavní vina je v kdenlive, že by mohli pouštět jednotlivé volání s nice a nedělají to. A také nerozporuji, že mnohé případy lze vyřešit příkazy z bashe s nastaveným nice/ionice. Ale stojím si za tím, že v desktopu se řeší jiná optimalizační úloha, nejde o férové rozdělení výkonu/io mezi procesy, ale o prioritu toho, co uživatel v konkrétním okamžiku požaduje.

[Heron]

Asi to z mého komentáře nebylo patrné, ale HandBrake (automaticky) používá všecha dostupná jádra (v tomto případě 8), stejně tak těch ffmpegů bylo 9 (používám make -j "počet cpu+1"). Celé tohleto běželo víc než 24h.

Ale stojím si za tím, že v desktopu se řeší jiná optimalizační úloha, nejde o férové rozdělení výkonu/io mezi procesy, ale o prioritu toho, co uživatel v konkrétním okamžiku požaduje.

Chápu, že někteří uživatelé mohou takovou funkcionalitu požadovat a nemám nic proti tomu, aby to tak šlo nastavit. Já bych si to nezapnul.

je počítač těžce použitelný

Co to konkrétně znamená? Pokud vezmu za příklad osmijádro, zcela nefunčkní prioritizaci a dejme tomu 9 procesů (8 na převod videa a devátý nějaký uživatelský), tak pořád na onen uživatelský proces zbývá 88% "jednoho jádra" (nebo 11% celého CPU, jak chceme). To přece není málo a na hromadu úloh, co se běžně na PC dělají to bude zcela dostačující (a to včetně přehrávání videí). Pokud je počítač "těžce použitelný" patrně to bude mít jinou příčinu, než zrovna prioritizaci procesů.

[lertimir]

... (používám make -j "počet cpu+1"). Celé tohleto běželo víc než 24h.

Ale stojím si za tím, že v desktopu se řeší jiná optimalizační úloha, nejde o férové rozdělení výkonu/io mezi procesy, ale o prioritu toho, co uživatel v konkrétním okamžiku požaduje.

Chápu, že někteří uživatelé mohou takovou funkcionalitu požadovat a nemám nic proti tomu, aby to tak šlo nastavit. Já bych si to nezapnul.

Zajímalo by mne, proč bys to nezapnul? Chápu, že zkušený informatik nebo systémový správce serverů se i k svému desktopu chová se znalostí procesů na serveru, a v argumentaci právě toto demostruješ. Na druhou stranu linuxový desktop používá i dost lidí, kteří o procesech nice, make -j ap. nemají ani tuchu. Pokud Linus má zájem o vyšší rozšíření desktopu, tak aby jej používalo čím dále více lidí, budou spíše z kategorie BFU, než ze správců serverů. V mém okolí je cca 10 lidí s linuxovým desktopem (část i díky mně) kteří s informatikou nemají nic společného, někteří z nich za léta používání ani nespustili terminálové okno, jiní jej používají jen na specializovanou akci (jako dcera bioložka v něm spouší statistiku v R-ku pokusů a nic více).

Pokud nový uživatel bude v situaci, kdy přijde kamarád s tím, že: "Ještě mi nakopiruj tady těch pár videí a alb na flešku. A než to dojede, tak bych se podíval na mail, kde přesně ten mejdan máme. Jaktože ti to nefunguje!? Vždyť to nic nedělá!? Co to máš za systém!?!!" Toho pak znalosti o zaplnění "dirty pages" zajímat nebudou. Bude ho zajímat, že systém reaguje nebo ne.

To, že systém v rozumném čase (100-300ms) zareaguje vždy (kromě naprosto nezbytných systémových událostí, jako třeba to, že chci pustit proces, který je dávno odswapovaný a musí se natáhnout) je podle mne pro široce akceptovatelný desktop nutností. (Dirty pages k tomu nutnému nepatří, protože tak, jak to vnímám, je že návrh správy stánek má někde v pozadí nevyslovené očekávání podobných přenosových rychlostí u všech blokových zařízení. A to nyní velmi neplatí. Od SSD s rychlostmi cca 400MB/s přes rotační disky s cca 100 MB až k pomalým flaskám a SD kartám s rychlostí i cca 4MB je 100:1 poměr. A mnohdy se na pomalá zařízení přesouvají velké objemy dat. A práce s stránkami by měla vědět jaké to zařízení fakticky je.) A jedna z vlastností, která by rychlost reakce systému podporovala, je to, aby front okno dostalo všechny zdroje (CPU/IO/GPU), které potřebuje do nějakého rozumného limitu (třeba 80-90%).

Už třeba to, že mnohdy při psaní textu se písmeno objeví s 0,5 s zpožděním, snižuje komfort. Pro toho kdo píše rychle, tak mnohdy píše po skupinkách. Přitom z hlediska celkové spotřeby času mezi procesy je jedno, jestli se zapíše ihned díky prioritě foregroudu, nebo až po prodlevě, kdy ho předběhl jiný proces. Ale pro uživatele to jedno není.

Ale i když o tom píši kriticky, nemyslím si, že linuxový desktop je na tom nějak strašně, jen má některé vlastnosti, na nichž by bylo záhodno pracovat. A také chápu, že ta prioritizace má mnohá úskalí, dost si pamatuji, když jsem na winXP, které je velmi postavené na prioritizaci foregroundu, spustil nějaký delší výpočetní proces, odešel od kompu, na systému se automaticky spustil spořič obrazovky, který tím pádem jel ve foregroundu a výkon si vzalo počítání pitomých křivek a neměl ho proces, který jsem potřeboval.

[Michal Kubeček]

Pozor, některé desktopové distribuce mají dnes defaultně zapnuté kernel.sched_autogroup_enabled, což v podstatě znefunkční niceness.

[nyan]

1. Kopirování velkých souborů na pomalejší zařízení blokuje celý stroj. I přes výrazné snížení parametru podle jaderných novin se to pořád někdy kouše.

Bohuzel, tohle me taky stve, a uz pekne dlouho...

[Heron]

To je podle mě očekávané chování. Cache se zkrátka použije na něco aktuálnějšího a stará data se vylijí. Naopak bych se velmi podivil, kdybych po zkopírování nějakého souboru a následující práce s ním zjistil, že se opět čte zbytečně z disku.

[Hans1024]

LRU je jen jeden z moznych pristupu a ne vzdy je vhodny. Je prakticky jedno, jestli se z 10GB kopirovaneho souboru nacachuje 4GB, nebo jen 3.9GB. Kdyz se kvuli tem 100MB navic vyhazi z pameti vsechny konfiguraky a jine mensi soubory vsech aplikaci v systemu (a to jenom proto, ze k nim par sekund nepristupovaly), clovek se nestaci divit, jak se to najednou trha.

[nyan]

Trosku neocekavane ale je, kdyz jsou v te same cache mmap()nute stranky kniznic a spousteneho kodu (a proti datum nejsou nijak prioritizovane). Takze ti kopirovani velkeho souboru vesele vylije z cache 80% spustitelneho kodu desktopu...

[petr_p]

Zrovna v dnešním desktopu, kde na každou kravinu se používá D-Bus, by tento přístup měl katastrofické důsledky.

[pet]

Takže když něco déletrvajícího v jednom okně spustím a mezitím co na to čekám tak se přepnu do jiného okna tak to abych čekal ještě déle? No to snad ne!!

[lertimir]

No to by záleželo, co v tom okně děláš. Zpozdilo by se to jen o to, co bys mu v tom druhém okně sebral na zdrojích. Tak je to i teď, jen díky čekání v tom front okně tomu sebereš méně.