Jaderné noviny – 1. 6. 2012: Atime opět páchá problémy (diskuse)

[Honza Jaroš]

V části Aktuální verze jádra máte nesprávně ukončený tag <b>, minimálně Firefox a Chromium pak zobrazují tučně celý následující text...

[Michal Ludvig]

Nastesti si s tim Firebug rychle poradil :)

[zxtlpn]

Opera jakbysmet.

[Nikola Ciprich]

co se Vám nelíbí? máte plnotučné jaderné noviny :)

[Šangala]

Na to furt ospale mžourám, přepínám velikost zobrazení fontů (Ctrl + +, ctrl + 0 apod.) a nic…

[Roger]

Krom toho je u asm/word-at-a-time.h špatně ukončený tt.

[Luboš Doležel (Doli)]

Ten tt mi utekl, ale nechápu, že jsem neviděl ten bold.

[Josef Kufner]

Se spíš divím, že se to neprožene stejnou věcí, jaká kontroluje validitu komentářů.

[Lampa]

Ale teď se ukázalo, že zaznamenávání relatime může být problémem na btrfs a relatime tomu moc nepomůže.

s/relatime/atime/

[cronin]

Je chyba v mojom prijímači, alebo je skutočne celý článok boldom?

[Robert Smol]

je, vcetne komentaru

[whata]

Příliš si nedokážu představit, na co mutt (či v podstatě cokoliv) potřebuje atime. Zajímat by jej měly jen změny, ne, zda ještě někdo další do mbox/Maildir přistupuje... Navíc používám noatime už snad všude a u mutt bych si problémů určitě všimnul.

Spíš, než řešit tuhle zbytečnost, bych atime prohlásil za obsolete nebo filesystem-specific a poslal jej tam, kam patří...

[Filip Jirsák]

V článku je to napsané – pro zjištění, zda už e-mail byl nebo nebyl přečten. Ostatní programy si to musí někde evidovat jako samostatný příznak, mutt to (asi) pozná porovnáním času modifikace s časem přečtení.

[Josef Kufner]

To jako že když mezi doručením a skutečným přečtením mailu proběhne zálohování, tak se vše označí jako přečtené?

[Filip Jirsák]

Já mutt nepoužívám, takže nevím. Ale připadá mi to jako jediné možné vysvětlení věty z článku: Klasickým příkladem je poštovní klient mutt, který bez atime nedokáže říci, zda v poštovní schránce je nepřečtená pošta.

[stativ]

Já teď kvůli tomu ze zvědavosti mutt nainstaloval a přestože mám vše připojené pomocí noatime, neměl jsem žádný problém s označením přečtené/nepřečtené.

[ET]

mno ono to asi nastava kdyz ctes muttakem z vice mist najednou - tady je nejaky vlaknoi work@round http://www.mail-archive.com/mutt-users@mutt.org/msg25052.html

[lib]

To jako že když mezi doručením a skutečným přečtením mailu proběhne zálohování, tak se vše označí jako přečtené?

Tak trochu. A nedělá to jen mut, atime také používá příkaz finger a jiné mailové klienty.

Osobně atime určitě za obsolete nepovažuji, spíše mne děsí souborové systémy, které nejsou schopny ani takovou trivialitu rozumně řešit. Na druhou stranu zřejmě mají jiné kvality, které jim dávají právo na existenci - v tom případě ať se mountují noatime. A na /var/spool je stejně asi vhodnější nějaký ext2345.

[Ash]

Myslím že rozumně atime řeší všechny souborové systémy.

[lib]

třeba FAT16 - tím, že to neřeší

[David Watzke]

Řeč byla o souborových systémech...

[lib]

sarcasm detected

[Heron]

Osobně atime určitě za obsolete nepovažuji, spíše mne děsí souborové systémy, které nejsou schopny ani takovou trivialitu rozumně řešit.

Podstatou diskuse je, co kdo považuje za rozumné. Souborové systémy to vyřešit schopné jsou, jsou to metadata jako jakákoliv jiná. I pro ten BTRFS. Otázkou je, zda akceptovat nutný zápis v případě pouhého čtení. A také je otázkou, zda alokace dalšího bloku pro změněná metadata je problém. To si musí zvolit administrátor daného systému. Má dost možností volby.

[j]

Podstatna je ta posledni veta - je to na adminovi. Ostatne distribuci nic nebrani v tom, aby trebas pri instalaci by default mountovala podobny FS prave s noatime.

Pokud nekdo chce/potrebuje bezpecny FS, tak by asi mel vedet proc ho chce. Vzdy je to neco za neco.

Samo, v principu by mozna nebylo od veci umoznit nejakou "lepsejsi" konfiguraci, ne jen bud vsechno nebo nic. Napr parametricky definovany chovani ruznych metadat, at admin sam zhodnoti, ktera jsou pro nej kriticka, a ktera jsou nepodstatna. Trebas atime potrebuje, ale jeho ztrata ho nejak zvlast mrzet nebude => muze se prepisovat na miste kde je a nepadat do snapu.

Jinak pokud ma nekdo potrebu snapu, velmi casto vytvari snapy na urovni disku (sektory) a ne na urovni FS, pak mu samo dalsi misto obsadi i prepis jednoho bitu. A je celkem uplne jedno jaky FS pouziva, stejne se to bude chovat na libovolnym FS. Takze me osobne spis prekvapuje, ze je nekdo prekvapen.

[Heron]

muze se prepisovat na miste kde je a nepadat do snapu

To nejde. To by se potom měnila metadata i v tom snapshotu (což není nic jiného jen další nezávislý oddíl (subvolume), který jen vznikl jako clon, snímek, již existujícího subvolume), který je na původních datech už z definice nezávislý. V případě COW souborových systémů je nutné při každé změně alokovat nový blok. Obě subvolume můžete chtít nezávisle na sobě měnit a zde už je jasné, že nemohou mít nadále provázaná metadata.

[J]

Pokud je mi to jedno, tak proc by to neslo? Samozrejme se tim naboura konzistence snapu (respektive jeho metadat), ale trebas mi to nevadi a je pro me dulezitejsi, aby cteni negenerovalo zapis.

Technicky jde totiz o mnohem zavaznejsi problem. To ze to "zere misto" je jedna vec, ale to vetsine lid problem nedela. Co jim ale problem delat bude, to je zasadni ztrata vykonu. FS kterej umi udelat snap, se totiz hodi (trebas) na umisteni databaze. A z te se vetsinou prevazne cte, a presne stim se pocita pri navrhovani prislusneho HW.

[Filip Jirsák]

FS kterej umi udelat snap, se totiz hodi (trebas) na umisteni databaze. A z te se vetsinou prevazne cte, a presne stim se pocita pri navrhovani prislusneho HW.

Tohle ale přece řeší parametr noatime. Nedovedu si představit případ, kdy bych chtěl atime aktualizovat, ale zároveň by mi nevadilo, že tam jsou v podstatě náhodné hodnoty. Takže volba ano/ne je podle mne dostačující.

[Heron]

Obávám se, že stavět FS na konceptu "když se rozejdou metadata, tak to nevadí" dost dobře nelze. Po snaspshotu jsou ty dve subvolume a jejich datové struktury nezávislé (pouze na počátku směrují do stejných datových bloků, což se díky COW změní po první zápisu do daného souboru) a takhle by se musel jeden atribut nějak provazovat. To nikdo dělat nebude.

Ad k těm snap a db. JJ, to je vynikající použití, bohužel zrovna PostgreSQL na BTRFS má zatím poněkud žalostný výkon (daný nutnou operací fsync, která je na btrfs poněkud drahá). To už je možná lepší replikace nebo PITR.