Jaderné noviny - 1. 4. 2009 (diskuse)

[tap]

Mam pocit, že toto je zlý preklad.

"Připojovací volba relatime je nyní výchozí; to znamená, že časy přístupu k souboru se aktualizují pouze v případě, že jsou novější než čas vytvoření nebo změny."

[trekker.dk]

Překlad je v pořádku, ale v originále je to špatně. Mělo by tam být "že jsou starší než"

[Pavel Stárek]

Tak jak to vlastně je? Relatime by mělo fungovat takto: vytvořím soubor v čase (třeba) 1.1.2010 00:00:01, v čase 2.1.2010 18:58:27 z něj něco načtu (čas přístupu k souboru by se neměl aktualizovat), mezi tím si z nějakého důvodu posunu hodiny dozadu a načtu soubor v čase 31.12.2009 23:59:59 -> v tomto případě by se tedy čas přístupu k souboru měl aktualizovat. Je to tak? Ale podle překladu a orig. zdroje by tato volba neměla smysl.

[Aleš Janda]

vytvořím soubor v čase (třeba) 1.1.2010 00:00:01, v čase 2.1.2010 18:58:27 z něj něco načtu ... načtu soubor v čase 31.12.2009 23:59:59 -> v tomto případě by se tedy čas přístupu k souboru měl aktualizovat

Neměl, neboť 2.1.2010 18:58:27 už je větší než 1.1.2010 00:00:01 a tudíž další aktualizace není třeba. Na času čtení v tomto případě nezávisí.

[Pavel Stárek]

No dobrá, a kdy by se tedy (za jakých podmínek) zapisovala (nějaká) změna na disk? (Nechci rýpat, ale skutečně by mně to zajímalo )

[Jirka Wolny]

Pokud jsem popis správně pochopil, mělo by to fungovat následovně:

1. Vytvořím soubor v čase 1.1.2009 00:00:01
2. Načtu soubor 2.1.2010 18:58:27, změní se atime (déle než 1 den)
3. Načtu soubor 2.1.2010 19:59:30, atime se nezmění
4. Změním soubor 2.1.2010 20:17:00
5. Načtu soubor 2.1.2010 21:10:10, atime se změní (původní atime bylo menší než čas poslení změny)
6. Načtu soubor 2.1.2010 21:30:12, atime se nezmění
7. Změním čas na 31.12.2009 23:59:59
8. Přečtu soubor, atime se nezmění (atime se nezmenšuje)

Takže:
A) Máme hrubou představu o tom, jestli se soubor používá nebo ne (chyba atime je maximálně jeden den).
B) Aplikace typu mutt jsou schopny detekovat, jestli od poslední změny souboru (body 1 a 4) došlo k jeho přečtení (atime je větší než čas poslední změny) a mohou zůstat v klidu, nebo ne (atime je menší než čas poslední změny) a musí reagovat.

[Pavel Stárek]

Jojo, už jsem to pochopil, nejde jen o časy přístupů (tedy obyčejné čtení ze souboru), ale taky se do toho míchají časy změn.

[Aleš Janda]

Neřeší BDI (nebo jiné vylepšení z 2.6.30) ten známý problém pomalosti při práci s diskem? A neřeší zlepšení virtuální paměti současnou neefektivnost cachování?

Pokud ano, bylo by to super - tohle jsou asi dvě z mála věcí, které mě na Linuxu trochu žerou

[Nicky726]

No vida a já chtěl už pomalu psát do poradny... Kopírování v řádu gigabajtů dat přes scp je dost opruz (nice to trochu zlepšuje ale ne moc), ta část upgradu sw, kdy dochází k vlastní instalaci také a největší sranda je, když se hashuje nějaký hodně velký torrent. A poslední dobou je to znát i pokud se pálí CD/DVD vysokou rychlostí.

[bibri]

Doufejme...

[petr_p]

Řekl bych, že neřeší. Oba vámi odkazované problémy jsou o tom, že cache blokových zařízení vytlačí z fyzické paměti stránky procesů. Problém je jak poznat, kdy to je přípustné, a kdy není. (Tedy tohle již Linux řeší tak, že nejprve vyhodí diskovou cache, a pak teprve začne swapovat data procesů). Přesněji problém je to, když máte v GIMPu namapovaný z disku velký velký obrázek a zároveň kopírujete velký soubor. Tady obě sady stránek patří diskové cachi (ostatně to i text GIMPu) a teď babo raď, kterou sadu upřednostnit.

Mám dojem, že v Linuxu není žádný takový rozhodovací nebo nastavitelný mechanismus a že ani o něm tyto noviny nebyly.

[Peta]

Konecne mi funguje televize na Linuxu...acer aspire 5920g. Jeste dalkove ovladani a bude preee.

Rozsireni linuxu brani mala podpora HW, ale posledni dobou se to brutalne zlepsuje. :)

Adelante comandante...

[Michal Ludvig]

Odkaz na AES-NI dokumentaci je špatně - je tam <a hef= místo <a href= takže to není klikcí link.

AES-NI dokument jsem zběžně prohlédnul a nemůžu si pomoct - proti AES instrukcím z VIA CPU (tzv VIA PadLock engine) je to zbytečně komplikované. To co VIA PadLock udělá jednou instrukcí je na Intelu AES-NI záležitost kódu na celou stránku. A bohužel ten intelí přístup ani nepřidává žádné možnosti které by VIA nenabízela. Škoda že se Inteláci nenechali inspirovat.

[Robert Krátký]

Odkaz na AES-NI dokumentaci je špatně - je tam <a hef= místo <a href= takže to není klikcí link.

Dík, opraveno.

[Mti.]

cekal bych, ze ma VIA Padlocka patentovaneho a pro Intel jakozto giganta v oboru je levnejsi patent o-jeb& vlastni konstrukci nez ho platit a riskovat pripadne potize. Bohuzel. Proc by jinak melo Sony,Apple,MS ,Yamaha...svuj vlastni(sranda je, ze nekteri i vic jak jeden) kodek na audio a podobne, kdyz by se mohli domluvit. (a zejmena, kdyz "NAM" by stacil ogg-vorbis a flac )

[geebranz]

Huge changes

storageshedsdesmoines.com