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

18. 6. 2012 | Luboš Doležel

Články - Jaderné noviny – 1. 6. 2012: Atime opět páchá problémy  

Aktuální verze jádra. Citáty týdne: Mel Gorman, Jens Axboe, Alan Cox. Vyšlo klibc 2.0. Začleňovací okno verze 3.5, část druhá. Atime a btrfs: nevhodná kombinace?

Obsah

• Aktuální verze jádra
• Citáty týdne: Mel Gorman, Jens Axboe, Alan Cox
• Vyšlo klibc 2.0
• Začleňovací okno verze 3.5, část druhá
• Atime a btrfs: nevhodná kombinace?

Aktuální verze jádra

Začleňovací okno řady 3.5 je nadále otevřené, takže ještě nevyšly žádné vývojové verze. Patche mezitím stále proudí do jádra; souhrn toho, co bylo zatím začleněno, najdete níže.

Stabilní aktualizace: během posledního týdne žádné nevyšly. Verze 3.0.33, 3.2.19, 3.3.8 a 3.4.1 se revidují.

Citáty týdne: Mel Gorman, Jens Axboe, Alan Cox

Lumpy reclaim měl svůj účel, ale někteří věřili, že jím je srazit systém na kolena pomocí trvalého trashování. Jiní to viděli tak, že jeho smyslem je komplikovat vmscan.c. Postupem času dostal měkčí boty a lepší chování, ale kompakce paměti musí být vylepšena, aby jej nahradila, takže tento patch lumpyho posílá do propadliště dějin.

-- Mel Gorman

Jiri [Kosina] je nyní označen za správce floppy.c. Veřejně jej při nejbližší příležitosti ocejchuji žhavým železem na čele.

-- Jens Axboe

Jako držitel práv v jádře zpochybňuji legalitu Matthewova návrhu a bylo by tragikomické, kdyby to skončilo tím, že Software Conservancy začne dělat právní kroky proti Fedoře.

-- Alan Cox

Vyšlo klibc 2.0

Vyšla verze 2.0 minimalistické knihovny klibc. Trochu opožděně kvůli průlomu do kernel.org, ale vývoj opět pokračuje. U větve 2.0 došlo k testování bootu a nasazování na Debianu, takže si jsme vcelku jisti, že by to většině z vás mělo fungovat, kdyby ne, dejte vědět. Největší změnou se zdá být řádná podpora bufferovaného I/O ve funkcích stdio.

Začleňovací okno verze 3.5, část druhá

Začleňovací okno pokračuje v plné síle, od minulých Jaderných novin se do hlavní řady dostaly další 4000 neslučovacích změn; celkem jde o více než 8600 změn ve verzi 3.5 a to ještě nejsme na konci. Nejvýznamnější změny viditelné uživatelům jsou:

• Patch autosleep implementující oportunistické uspávání v androidím stylu (s odlišným API). S touto změnou souvisí nový příznak v epollu (EPOLLWAKEUP), který způsobuje aktivaci události probuzení, což zabraňuje uspání, když je ke zpracování dostupná nějaká událost.
• Přepracování jmenných prostorů uživatelů přibližuje jádro bezpečnému spouštění procesů jako root v kontejneru.
• Pole RAID10 spravovaná vrstvou MD lze nyní upravovat.
• Po letech úsilí byl začleněn subsystém uprobes. Více se dozvíte v tomto článku.
• Souborový systém tmpfs nyní podporuje řídké soubory a volby SEEK_DATA a SEEK_HOLE v lseek().
• Pokračuje odstraňování starého kódu; obětmi jsou podpora řadiče Microchannel, staré ovladače CRIS RTC, ovladač imxmmc, kód swap tokenu a mechanismus lumpy reclaim.
• Spousta různých ovladačů.

Změny viditelné vývojářům zahrnují:

• Tabulka výjimek v jádře může nyní být řazena při sestavování, což trochu zrychluje bootování.
• ALSA nyní podporuje „dynamická PCM“ zařízení, to znamená zařízení, která jsou rozdělena na front a back end, což umožní libovolné routování zvukových dat mezi zařízeními front a back endu.
• Patch alokátoru souvislé paměti, který usnadňuje život na systémech, kde jsou občasně zapotřebí velké kusy souvislé paměti, byl konečně začleněn. Součástí přetažení bylo i kompletní předělání subsystému mapování ARM DMA, přidání podpory CMA a podpory pro jednotky správy I/O paměti.
• Subsystém sdílení DMA bufferů získal podporu pro mapování bufferů do uživatelského prostoru. Přibyla i funkce dma_buf_vmap() pro mapování bufferů (s využitím oblasti vmalloc()) do jaderného prostoru.
• <asm/word-at-a-time.h> byl (Linusem) značně předělán, aby byl na všech architekturách efektivnější; strnlen_user() bylo přepsáno, aby bylo používáno obecně.
• LED subsystém nyní podporuje jednorázové časované operace; více v ledtrig-transient.txt.
• Subsystém detekce a opravy chyb (EDAC) byl masivně přepracován, aby lépe zvládal současné procesory a paměťové řadiče.

V době psaní tohoto textu zbývá do konce začleňovacího okna verze 3.5 ještě několik dnů. Po jeho uzavření vyjde závěrečný článek.

Atime a btrfs: nevhodná kombinace?

Unixové a unix-like systémy tradičně zaznamenávaly čas posledního přístupu všech souborů na systému. Tenhle přístup se v posledních letech přestal lidem zamlouvat, a to z jednoduchého důvodu: zapisování posledního času přístupu („atime“) zabírá spoustu šířky pásma I/O při čtení velkého množství souborů; vizte například tento článek z roku 2007. Nejhorší problémy s atime byly potlačeny přechodem k používání „relatime“ ve výchozím stavu; relatime aktualizuje atime maximálně jednou denně u souborů, které se nezměnily. Ale teď se ukázalo, že zaznamenávání atime může být problémem na btrfs a relatime tomu moc nepomůže.

Jednou z hlavních vlastností btrfs je copy-on-write. Bloky na disku nejsou nikdy měněny na svém původním místě; místo toho, jakmile je potřeba commitovat změnu, je dotčený blok okopírován a přepsán na novém umístění. Copy-on-write se týká metadat i dat; pokud jsou metadata souboru (jako například čas posledního přístupu) změněna, blok obsahující metadata bude okopírován na nové místo. To znamená, že operace, která čte mnoho souborů (například vytváření tar archivu nebo rekurzivní grep), může kvůli aktualizacím atime zapříčinit kopírování a přepisování spousty bloků s metadaty.

Není nutné dodávat, že to výkonu neprospívá, ale to ještě není to nejhorší. Jak Alexander Block upozornil, skutečný problém má co do činění se vztahem mezi atime, copy-on-write a snapshoty.

Btrfs poskytuje funkci rychlého snapshotování, která umožňuje vytvoření kopie stavu souborového systému v určitém čase. Jakmile je snapshot vytvořen, sdílí všechna data a metadata s „trunkem“ filesystému. Pokud je soubor změněn, výsledná operace copy-on-write oddělí trunk od snapshotu s tím, že se zachovají obě kopie dat. Takže snapshoty lze vnímat jako nenákladné, dokud se toho na souborovém systému moc neděje. Snapshoty sdílejí data a metadata, tudíž nepotřebují tolik dodatečného prostoru.

S atime je ale situace trochu jiná. Pokud někdo udělá snapshot systému a pak na něm udělá rekurzivní grep, tak může dojít k aktualizaci času posledního přístupu na všech otevřených souborech. To pak vede k copy-on-write operacím na inode každého souboru, což může vést k duplikaci spousty nebo všech inodes v souborovém systému. To zase vede ke spotřebě místa souborovým systémem; Alexander zaslal příklad, kde rekurzivní grep způsobí zmizení 2,2 GB volného místa. To je překvapivý důsledek operace, která měla být read-only.

V době, kdy se diskové kapacity počítaly na megabajty, se říkalo, že jedinou standardní funkcí unixových systémů bylo MoTD, které říkalo lidem, že mají pročistit své soubory. Atime pak bylo často používáno administrátory, kteří se v nouzi snažili uvolnit nějaké místo; jednoduše vyhledali málo užívané soubory a v závislosti na zoufalosti situace pak poslali seznam nepoužívaných souborů uživatelům, nebo je prostě přesunuli na pásku. Je docela ironie, že funkce, která kdysi mimo jiné pomáhala uvolňovat místo na disku, je nyní součástí problému.

Je třeba upozornit, že volba relatime tu moc nepomůže. K přepsání inode stačí jen jedna aktualizace atime. To, že relatime tyto aktualizace omezuje na maximálně jednou denně, až tak nepomáhá.

Uživatele také nepotěší další aspekt problému, na který Alexander poukázal: protože čtení dat může vyvolat spotřebu dat na souborovém systému, operace čtení mohou selhat s chybou „nedostatek místa na disku“ na plném souborovém systému. To může zkomplikovat nebo znemožnit nápravu problému okopírováním dat pryč ze souborového systému. Jakmile se to stane, tak už se nelze divit, že bude uživatel přemýšlet, proč vlastně sledování posledního přístupu potřebuje.

Proto Alexander navrhl, že by nemuselo být špatné defaultně používat „noatime“ na btrfs, i když to znamená, že se btrfs bude chovat jinak než jiné souborové systémy. Tento nápad byl rychle zamítnut s tím, že stále existují aplikace, které pro své fungování atime potřebují. 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. Programy, které pročišťují dočasné adresáře (tmpreaper nebo tmpwatch) bez atime selžou. Jsou tu i hierarchická úložiště, kde se atime používá k rozhodování, kdy se soubory mají přesunout na pomalejší úložiště. Takže atime musí zůstat, leda by se uživatelé dostali do jiných nepříjemných trablí.

Prozatím je jedinou útěchou pro uživatele, kterým to vadí, explicitní mountování s volbou „noatime“. Navíc by bylo možné udělat nějaké úpravy v btrfs, aby byl problém potlačen; Boaz Harrosh navrhl zákaz aktualizací atime, jakmile se volné místo dostane pod určitou hranici, nebo přesunutí atime do jiné datové struktury. Ale nikdo asi na takových řešeních nepracuje. Takže se může stát, že jak se bude používání btrfs rozšiřovat, uživatelé budou občas překvapeni, že čtení souboru může způsobit spotřebu místa na disku.

Diskuse k tomuto článku

[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.