Tak po zapnutí swapu bohužel problém přetrvává. Při rozbalování rar souboru (zdrojový i cílový soubory byly na jednom NTFS externím USB disku) programem 7z opět došlo ke spotřebování skoro celé paměti, systém opět zatuhával... Sledoval jsem jak se plní paměť během "rozbalování" (ono když je to uložené metodou store, tak tam toho moc na rozbalování není). Při volných 100MB opět se zasekávala myš a i systém jako celek... Navíc by mě zajímalo kde je problém: i kdyby byl použitý nějaký hustý kompresní algoritmus, tak přece při rozbalování se nebude stávat, že se volná paměť se bude donekonečna zmenšovat(podrobnosti jsou na konci)..

Napadají mě tedy tyhle možnosti:
1. NTFS ovladač je blbý, že nepodporuje něco jako MMAP
2. kromě toho je i pomalý (na 1.5GHz atomu při kopírování NTFS-RAM má 50% CPU load)
3. linux má blbou správu paměti (když už vím, že radši neodstřelí nenasytný proces,aby prý nedošlo ke ztrátě dat, ve výsledku dojde zatuhnutí PC) tak třeba prostě nějak neuvolňuje pamět
4. v nějakém mezi článku nefunguje bufferované čtení souboru a prostě se snaží celý soubor narvat do RAM





Nevím, ale mám pocit, že v linuxu ohledně správy paměti (ale i mj. třeba i záseků způsobeného zahlcením video RAM ) je něco shnilého.

@dell ~ % free -h
             total       used       free     shared    buffers     cached
Mem:          3,9G       3,8G       110M        85M       761M       559M
-/+ buffers/cache:       2,5G       1,4G
Swap:          75M        75M         4K

PS: když už jsem psal o přenosu souboru nadisk, umí nějaké systémy (spíš řadiče HDD) třeba při kopírování, že OS dá příkaz na kopírování určitých bloků na HDD, tak, že řadič HDD kopíruje, ale bez nutnosti aby SATA/USB rozhraním OS ty data četl a ty SAMÁ nová data zase do rozhraní posílal k zápisu?

A poslední věc... Od zapnutí swapu při vysokém obsazení paměti pozoruji vysoké zatížení CPU procesem [kswapd0]