Jaderné noviny - 1. 4. 2009

12. 5. 2009 | Jirka Bourek | Jaderné noviny | 3536×

Aktuální verze jádra: 2.6.29. Citáty týdne: Alan Cox, Andrew Morton, Linus Torvalds. Začleňovací okno 2.6.30, část 1. Odstranění pdflush. To obrovské vlákno o souborových systémech: Priorita žurnálování; data=ordered, fsync() a fbarrier(); relatime; I/O bariéry; Ladění výkonu.

Obsah

• Aktuální verze jádra: 2.6.29
• Citáty týdne: Alan Cox, Andrew Morton, Linus Torvalds
• Začleňovací okno 2.6.30, část 1.
• Odstranění pdflush
• To obrovské vlákno o souborových systémech
  • Priorita žurnálování
  • data=ordered, fsync() a fbarrier()
  • relatime
  • I/O bariéry
  • Ladění výkonu

Aktuální verze jádra: 2.6.29

Současné stabilní jádro je stále 2.6.29. Začleňovací okno 2.6.30 je otevřené (vizte níže) a během minulého týdne nebyla vydána žádná stabilní aktualizace.

Stabilní aktualizace 2.6.29.1 je revidována. Obsahuje něco přes 40 oprav a lze ji očekávat 2. nebo 3. dubna.

Citáty týdne: Alan Cox, Andrew Morton, Linus Torvalds

Opravdu je potřeba, aby si někdo sedl a vytvořil pořádný model chování VM v nástroji jako je netlogo, místo toho, aby se pokračovalo v nepřetržitém přidávání čím dál tím složitějších a tím nepředvídatelnějších hacků. Tímto způsobem budeme moci lépe pochopit, co se děje a proč.

-- Alan Cox

Je velké zklamání, že se za celou tu dobu nikdo nepokusil o jakékoliv rozumné ladění těchto hodnot - akorát stále děláme nepořádek snahou vybrat do základního jádra lepší kouzelná čísla.

Možná bychom laditelné hodnoty měli nastavit na 99,9 %, aby byly tak protivné, aby se o to někdo pokusil.

-- Andrew Morton

My lidé od jádra jsme opravdu jedineční. Očekávat, že normální aplikace vyvinou stejnou snahu jako my (co se škálovatelnosti, ošetřování chyb, bezpečnosti týče), prostě není realistické.

-- Linus Torvalds

Začleňovací okno 2.6.30, část 1.

V době psaní tohoto článku bylo do hlavní řady pro vydání 2.6.30 začleněno téměř 6200 neslučovacích sad změn. Začleňovací okno je tedy skutečně otevřené. Pro 2.6.30 je již připravena spousta věcí, přičemž další určitě přibudou. Změny viditelné pro uživatele prozatím zahrnují:

• 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. Další začleněná změna také způsobuje, že se čas přístupu aktualizuje alespoň jednou denně. Uživatelé, kteří potřebují, aby se čas přístupu aktualizoval při každém přístupu, mohou použít připojovací volbu "stricatime". Více informací o této změně vizte v tom obrovském vlákně o souborových systémech.

• Už byly konečně začleněny patche správy integrity. Mezi jinými věcmi tento kód umí použít modul důvěryhodné platformy [trusted platform module, TPM] k tomu, aby se ujistil, že se soubory v systému nebylo manipulováno, a ke vzdálenému ověřování.

• Také byl konečně začleněn TOMOYO Linux. TOMOYO je na cestách založený bezpečnostní modul podobný (ale významně se odlišující od) AppArmoru.

• Je zde nová sysfs proměnná cpuinfo_transition_latency pro řízení frekvence CPU; informuje uživatelský prostor o tom, jak dlouho CPU trvá přejít z jedné frekvence na jinou.

• Přibyla podpora pro kryptografické instrukce AES-NI zaváděné do procesorů Intelu; detaily o AES-NI vizte v pojednání na softwarecommunity.intel.com.

• Architektury x86_64 a SuperH získaly podporu pro kexec skok.

• KVM má nyní rozhraní pro ladění hosta, což hostiteli umožňuje interaktivně ladit hostované systémy. KVM také získalo podporu pro procesory PowerPC e500.

• Je zde nové API do uživatelského prostoru pro detailní kontrolu nad časovými značkami síťových paketů. Detaily vizte v Documentation/networking/timestamping.txt.

• Síťová vrstva nyní podporuje protokol Reliable Datagram Sockets (RDS). Více informací vizte v Documentation/networking/rds.txt.

• Architektura x86 má nyní možnost umístit na konec jaderného zásobníku hodnotu "kanárka"; pokud se tato hodnota změní, zásobník (náhodou nebo zlým úmyslem) přetekl.

• Hodně se pracovalo na souborovém systému Reiserfs; pročišťování kódu, vylepšení podpory SELinuxu a zlepšení výkonnosti. Pravděpodobně se jedná o poslední sadu aktualizací reiserfs.

• Bylo začleněno obvyklá várka nových ovladačů. Mezi ně patří:

  • Bloková vrstva: hostitelské řadiče PCI-Express SAS 6Gb/s

  • Grafika: GPU AMD R6xx/R7xx (prozatím pouze 2D)

  • Síťování:
    • sériové modemy USB Qualcomm,
    • 802.11b/g karty Marvell Libertas 8686 SPI,
    • bezdrátové karty Marvell 88w8xxx TOPDOG PCI/PCIe,
    • bezdrátové adaptéry Prism54 SPI (stlc45xx),
    • USB bezdrátové adaptéry Atmel at76c503/at76c505/at76c505a,
    • Ethernet MAC zařízení OpenCores 10/100 Mbps a
    • USB zařízení Atheros "otus" 802.11n.
  • Zvuk:
    • telefony Mitac MIO A701,
    • kodeky Wolfson Micro WM840 a WM9705,
    • moduly Wolfson Microelectronics 1133-EV1,
    • DAC zařízení Atmel Audio Bitstream,
    • AC97 řadiče Atmel,
    • S/PDIF vysílače Asaki-Kasei AK4104,
    • karty Echo Audio IndigoIOx a IndigoDJx,
    • karty Turtle Beach Classic, Fiji a Pinnacle,
    • zvukové karty Asus Xonar Essence STX.
  • Video/DVB:
    • USB kamery Mars-Semi MR97310A,
    • širokopásmové nízkopříkonové CMOS tunery Freescale MC44S803,
    • USB kamery SQ Technologies založené na SQ905,
    • rozhraní pro kamerový senzor i.MX3x,
    • satelitní demodulátory ST STV0900,
    • křemíkové tunery ST STV6110,
    • USB kamery SQ Technologies založené na SQ905C,
    • křemíkové tunery Zarlink ZL10036,
    • tunery LG Electronics založené na LGDT3305,
    • USB zařízení Hauppauge HD PVR a
    • USB2.0 DVB-T přijímače Intel CE6230.
  • Procesory a systémy:
    • SuperH SH7786,
    • referenční desky ESPT-Giga založené na SH7763,
    • referenční platforma SMSC s CPU SH7709S,
    • systémy Palm LifeDrive a Tungsten|T5,
    • řídící desky Brivo Systems LLC ACS-5000,
    • platformy Dave/DENX QongEVB-LITE,
    • vývojové desky Marvell RD-78x00-mASA,
    • procesory Marvell PXA168 and PXA910,
    • procesory TI OMAP850,
    • desky OMAP 3430 SDP,
    • internetové tablety Nokia RX-51,
    • systémy Teltonika 3G Router RUT100,
    • jádra Faraday FA526,
    • systémy na čipu rodiny Cortina Systems Gemini,
    • PowerPC desky GE Fanuc SBC310 a PPC9A,
    • desky Freescale Media5200,
    • systémy AMCC Redwood(460SX),
    • desky Phytec phyCORE-MPC5200B-IO (pcm032) a
    • desky Freescale MPC8544 ("Socrates").
  • Ostatní:
    • šifrovací akcelerátory AMCC PPC4xx,
    • zařízení pro PCI časové kódy [PCI time code] Adrienne Electronics Corporation,
    • čtečky čarových kódu Symbol 6608,
    • řadiče E-Ink Broadsheet/Epson S1D13521,
    • i2c řadiče NXP Semiconductor PCA9665 a
    • senzorové čipy Siemens Syleus a Hades.

• USB ovladače "Phidgets" byly odstraněny; uživatelé by se měli přesunout k ovladačům v uživatelském prostoru.

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

• Patch adaptivních rotujících [spinning] mutexů byl začleněn. Tato změna způsobuje, že se mutexy chovají jako spinlocky v případě, že dojde k soupeření. Pokud (a jenom tehdy když) je zámek držen kódem na jiném CPU, poběží kód mutexu ve smyčce s předpokladem, že bude zámek brzy uvolněn. Výsledkem tohoto chování je významné zlepšení výkonnosti. Btrfs, který měl vlastní implementaci točících se mutexů, byl konvertován na nové mutexy.

• Do API crypto byla přidána nová sada funkcí, která umožní kompresi a dekompresi dat po částech.

• Členská proměnná struct device bus_id je pryč; kód, který potřebuje tuto informaci, by měl místo ní použít makro dev_name()

• Je zde nová funkce pro časovače:

  int mod_timer_pending(struct timer_list *timer, unsigned long expires);

Je podobná mod_timer() s tím rozdílem, že nereaktivuje časovač, který již vypršel.

• Ve struct file_operations došlo k nějakým změnám ohledně funkce fasync(). Tato funkce nyní zodpovídá za udržování bitu FASYNC v struct file; také je nyní volána, aniž by byl držen velký jaderný zámek [big kernel lock]. A nakonec - kladná návratová hodnota fasync() je mapovaná na nulu, což znamená, že návratová hodnota fasync_helper() může být vrácena přímo fasync(). (To je skromný příspěvěk do 2.6.30 od Jonathana Corbeta, autora tohoto článku.)

• SCSI vrstva má nyní novou podpůrnou knihovnu pro podporu zařízení ukládajících objekty [object storage device]; detaily vizte v Documentation/scsi/osd.txt.

• Mechanismus "subarchitektury" u x86 byl odstraněn, protože nyní ho již žádná architektura nepoužívá. V důsledku této změny byla odstraněna architektura Voyager.

• x86 je také první architektura, která používá nový paměťový alokátor pro jednotlivá CPU [per-CPU memory allocator] začleněný do 2.6.30. Tento alokátor na úrovni API mění málo, ale poskytne efektivnější a flexibilnější správu proměnných pro jednotlivá CPU.

• Byla přidána podpora pro kompresi jádra algoritmy bzip2 nebo lzma. Podpora pro starý formát zImage byla odstraněna.

• Ve výchozím nastavení je nyní povolena infrastruktura pro asynchronní volání funkcí.

• Byly začleněny nástroje pro ladění DMA API.

• Pole owner struktury struct proc_dir_entry bylo vyjmuto, což způsobilo mnoho změn v celém stromě.

Pokud vydrží obvyklý dvoutýdenní vzor, lze očekávat, že začleňovací okno zůstane otevřené do přibližně 9. dubna. Tempo, jakým proudí změny do hlavní řady, se pravděpodobně v druhé polovině začleňovacího okna zpomalí - alternativou by bylo, že by tento vývojový cyklus byl o mnoho větší než kterýkoliv z jeho předchůdců. Je nicméně jistě, že do 2.6.30 bude začleněno více zajímavých změn.

Odstranění pdflush

Originál tohoto článku napsal Goldwyn Rodrigues

Jaderná cache stránek udržuje v paměti kopie datových bloků, které patří do souborů na trvalém úložišti. Stránky, do kterých procesor zapíše, ale které ještě nejsou zapsány na disk, se hromadí v cache a jsou známy jako "špinavé" [dirty] stránky. Množství špinavé paměti je vypsáno v /proc/meminfo. Stránky v cache jsou na disk uloženy po 30 sekundách, za zapisování špinavých stránek na disk je zodpovědná sada jaderných vláken nazvaná pdflush. Může se tak stát buď explicitně v reakci na volání sync(), nebo implicitně v případě, že cache stránek dojdou stránky, stránky byly v paměti příliš dlouho nebo je v cache stránek příliš mnoho špinavých stránek (což určuje /proc/sys/vm/dirty_ratio).

V systému vždy běží dva až osm vláken pdflush. Počet vláken je určen zátěží cache stránek; nové vlákno pdflush se vytvoří, když žádné z existujících vláken nebylo po více než vteřinu v klidu a v pracovní frontě pdflush zbývá nějaká práce. Na druhou stranu, jestliže naposledy aktivní vlákno pdflush spalo více než sekundu, je jedno vlákno ukončeno. Vlákna jsou ukončována jenom do doby, než zbývá pouze minimální počet vláken. Současný počet běžících vláken pdflush je k vidění v /proc/sys/vm/nr_pdflush_threads.

V souvislosti s pdflush se postupem času objevilo mnoho problémů. Vlákna pdflush jsou společná pro všechna bloková zařízení, ale má se za to, že by se chovala lépe, kdyby se zaměřila pouze na jeden disk. Soupeření mezi vlákny se brání použitím příznaku BDI_pdflush struktury backing_dev_info, ale toto propojení může také omezovat výkonnost zpětného zápisu [writeback]. Další problém s pdflush je vyčerpání požadavků. Pro každou frontu v systému je k dispozici pevně daný počet I/O požadavků; pokud je tento limit překročen, jakákoliv aplikace požadující I/O bude blokovat čekáním na novou pozici. Vzhledem k tomu, že pdflush pracuje na několika frontách, nemůže blokovat na jediné frontě; proto nastaví příznak pro informace o zpětném zápisu wbc->nonblocking. Pokud další aplikace pokračují se zápisy na zařízení, pdflush opakovaně neuspěje při alokaci pozice požadavku. To může vést k vyhladovění přístupu ke frontě, pokud pdflush opakovaně zjistí, že je fronta zahlcená.

Jens Axboe ve své sadě patchů předkládá novou myšlenku používání ukládacích vláken pro každé info o úložném zařízení [backing device info, BDI] jako náhradu vláken pdflush. Na rozdíl od vláken pdflush se ukládací vlákna vyhrazená pro BDI zaměřují na jediný disk. S tímto způsobem ukládání, pokud je request_queue zahlcená, dojde k blokování při alokacích požadavků, čímž se zamezí vyhladovění požadavků a poskytne se tak férovější přístup.

S pdflush je seznam špinavých inodů uložen u superbloku souborového systému. Vzhledem k tomu, že pro-BDI ukládač potřebuje vědět o špinavých stránkách, které mají být uloženy, podle úložného zařízení, seznam je nyní ukládán u BDI. Volání, která vynucují uložení špinavých inodů pro superblok, vyústí v uložení inodů ze seznamu špinavých inodů na úložném zařízení pro všechna zařízení uvedená pro souborový systém.

Stejně jako u pdflush je zpětný zápis pro-BDI řízen datovou strukturou writeback_control, která instruuje kód zpětného zápisu, co dělat a jak zpětný zápis provést. Důležitá pole této struktury jsou:

• sync_mode: definuje způsob, jakým má být prováděna synchronizace s ohledem na zamykání inodů. Jestliže je nastaveno na WB_SYNC_NONE, zpětný zápis přeskočí zamčené inody, kdežto při nastavení WB_SYNC_ALL se se zpětným zápisem čeká, než jsou zamčené inody odemčeny.

• nr_to_write: počet stránek k zapsání. Tato hodnota se snižuje s tím, jak jsou zapisovány stránky.

• older_than_this: Pokud není NULL, uloží se všechny inody starší než hodnota v tomto poli (udaná v jiffies). Toto pole má přednost před nr_to_write.

Struktura struct bdi_writeback uchovává všechny informace potřebné pro ukládání špinavých stránek:

struct bdi_writeback {
    struct backing_dev_info *bdi;
    unsigned int nr;
    struct task_struct      *task;
    wait_queue_head_t       wait;
    struct list_head        b_dirty;
    struct list_head        b_io;
    struct list_head        b_more_io;

    unsigned long           nr_pages;
    struct super_block      *sb;
};

Struktura bdi_writeback je inicializována, když je zařízení registrováno pomocí bdi_register(). Pole v bdi_writeback jsou:

• bdi: backing_device_info spojené s tímto bdi_writeback,

• task: obsahuje ukazatel na výchozí ukládací vlákno, které je zodpovědné za vytváření dalších vláken, která mají na starosti ukládání,

• wait: čekací fronta pro synchronizaci s ukládacími vlákny,

• b_dirty: seznam všech špinavých inodů k uložení pro toto BDI,

• b_io: inody parkované pro I/O,

• b_more_io: další inody parkované pro I/O; všechny inody naplánované k uložení se ukládají do tohoto seznamu předtím, než jsou přesunuty do b_io,

• nr_pages: celkový počet stránek k uložení a

• sb: ukazatel na superblok souborového systému, který sídlí na tomto BDI.

nr_pages a sb jsou parametry asynchronně předávané do ukládacího vlákna BDI a během života bdi_writeback nejsou pevné. To se dělá kvůli zařízením, která mají více souborových systémů, tudíž více superbloků. S několika superbloky na jednom zařízení lze požadovat sync na jediný souborový systém na zařízení.

Funkce bdi_writeback_task() čeká po dobu dirty_writeback_interval, jejíž výchozí hodnota je 5 sekund, a periodicky spouští wb_do_writeback(wb). Jestliže během pěti minut nejsou zapsány žádné stránky, ukládací vlákno se ukončí (se zpožděním dirty_writeback_interval.) Pokud je později potřeba zpětné zapisování (po ukončení), jsou výchozím ukládacím vláknem vytvořena nová ukládací vlákna.

Ukládání při zpětném zápisu se provádí dvěma způsoby:

• styl pdflush: Tento způsob se použije v reakci na explicitní požadavek na zpětný zápis, například při synchronizaci stránek inodů superbloku. wb_start_writeback() je volána s informacemi o superbloku a počtu stránek, které mají být uloženy. Funkce se pokouší získat strukturu bdi_writeback spojenou s BDI. Pokud uspěje, uloží ukazatel na superblok a počet stránek k uložení do struktury bdi_writeback a probudí ukládací vlákno, aby provedlo samotné zapisování pro superblok. Toto se odlišuje od způsobu, jakým zapisuje pdflush: pdflush se pokouší zabrat si zařízení, na které se má zapisovat, čímž blokuje zapisování ostatními procesy.

• styl kupdated: Jestliže nejsou žádné explicitní požadavky na zpětný zápis, vlákno se periodicky probouzí, aby uložilo špinavá data. Když je poprvé jedna ze stránek inodu uloženého v BDI zašpiněna, čas, kdy se tak stalo, se uloží v adresovém prostoru inodu. Kód pro periodické zapisování prochází seznam inodů superbloku a zapisuje špinavé stránky starší, než je zadaný čas. To probíhá jednou za dirty_writeback_interval, jehož výchozí hodnota je pět sekund.

Po revizích svého prvního pokusu přidal Jens možnost mít několik ukládacích vláken pro každé zařízení v reakci na návrhy Andrewa Mortona. Dave Chinner navrhl, že souborové systémy by rády měly jedno ukládací vlákno pro každou alokační skupinu [allocation group]. V sadě patchů (druhé verzi), která následovala, přidal Jens nové rozhraní k superbloku, které vrací strukturu bdi_writeback spojenou s inodem:

struct bdi_writeback *(*inode_get_wb) (struct inode *);

Pokud je inode_get_wb NULL, vrací se výchozí bdi_writeback BDI, což znamená, že pro BDI je jenom jedno vlákno bdi_writeback. Maximální počet vláken, které lze pro BDI spustit, je 32.

Počáteční experimenty, které Jens provedl, ukázaly 8% nárůst výkonnosti na jednoduchém SATA disku se spuštěným Flexibilním benchmarkem souborového systému [Flexible File System Benchmark, ffsb]. Rozvržení souborů bylo v porovnání s vanilla jádrem, podle toho co hlásil vmstat, hladší s rovnoměrným rozložením uložených bufferů. Se souborovým systémem btrfs na deseti discích fungovalo ukládání založené na jednotlivých vláknech pro BDI o 25 % rychleji. Zpětný zápis je uložen v Jensově gitovém stromu blokové vrstvy (git://git.kernel.dk/linux-2.6-block.git) ve větvi "writeback". Druhá iterace zatím neobdržela žádné komentáře, ukládací vlákna pro BDI zvlášť však stále nejsou připravena na začlenění do stromu 2.6.30.

Poděkování: díky Jensovi Axboemu za revizi a vysvětlení některých aspektů sady patchů.

To obrovské vlákno o souborových systémech

Dlouhé, vysoce technické a živé diskuze rozhodně nejsou v e-mailové konferenci linux-kernel nic neslýchaného. Nicméně, i podle měřítek linux-kernel bylo vlákno, které následovalo po oznámení 2.6.29, ohromující. Ve stech zprávách se jaderní vývojáři dohadovali o několika aspektech toho, jak fungují souborové systémy a blokové I/O na současných linuxových systémech. Na konci (autor článku je optimista a předpokládá, že diskuze skončila) jsme měli vcelku horko - a nějaké užitečné, konkrétní výsledky.

Lze jenom litovat Jespera Krogha, který téměř určitě nevěděl, do čeho se dostane, když zaslal hlášení o procesu, který na několik minut uvízl při čekání na diskové I/O. Jediné, v co doufal, bylo, že obdrží návrh, jak se vyhnout tomuto druhu zpoždění - která jsou projevem známého problému fsync() na ext3 - na svém serveru. Ve skutečnosti místo toho dosáhl toho, že jeho jméno bylo v celé diskuzi.

Priorita žurnálování

Jeden z problémů je alespoň částečně pochopitelný: Volání fsync() na souborovém systému ext3 vynutí zápis žurnálu souborového systému (a s ním spojených dat) na disk. Tato operace může vyvolat hodně zapisovací aktivity, na kterou se musí čekat. Současné I/O plánovače dávají přednost operacím čtení před zápisem - to je většinou racionální volba: Na čtení většinou čeká nějaký proces, kdežto zapisovat lze asynchronně. Zápis žurnálu nicméně asynchronní není a může způsobit, že spousta věcí musí čekat, než doběhne. Bylo by tedy lepší nevkládat I/O operace žurnálu na konec fronty.

Ve skutečnosti by bylo lepší, aby operace se žurnálem vůbec nesoupeřily se zbytkem systému. Za tímto účelem Arjan van de Ven dlouho spravuje jednoduchý patch, který dává vláknu kjournald realtime I/O prioritu. Podle Alana Coxe tento patch stačí k tomu, aby mnoho problémů zmizelo. Patch se nicméně do hlavní řady nedostal, protože ho zablokoval Andrew Morton. Tento patch podle něj nereaguje na skutečný problém a způsobuje, že spousta dalšího I/O provozu těží ze zvýšené priority. Andrew říká, že skutečná oprava je složitější:

Závěr je, že je potřeba, aby se někdo pořádně zahrabal do samého srdce logiky JBD transakcí, ale nikdo se ještě nepřihlásil. Pokud to uděláme a zjistí se, že by to prostě bylo příliš těžké, pak ano, v takovou chvíli možná bude čas podívat se po lécích proti bolesti.

Ať už jde o léky proti bolesti, nebo ne, má tento přístup své příznivce. Souborový systém ext4 má novou připojovací volbu (journal_ioprio), kterou lze použít k nastavení I/O priority pro operace se žurnálem; výchozí je o něco vyšší než normální (ale ne realtime). Ted Ts'o nedávno zaslal sérii patchů pro ext3, která pro některé zápisy žurnálu nastavuje WRITE_SYNC. Tento příznak označuje operaci jako synchronní, což zabrání tomu, aby byla blokována dlouhou sérií čtecích operací. Podle Teda tato změna trochu pomůže, alespoň pokud probíhá hodně čtecí aktivity. Změny v ext3 ještě nebyly v době psaní tohoto článku do 2.6.30 začleněny (to nebyl žádný z Tedových stromů), ale je pravděpodobné, že se dostanou do hlavní řady před 2.6.30-rc1.

data=ordered, fsync() a fbarrier()

Skutečný problém je nicméně podle Teda režim data=ordered v ext3. Díky tomuto režimu je ext3 relativně robustní v případě pádu, ale, jak říká Ted, děje se tak za cenu výkonnosti a podpory špatného programování v uživatelském prostoru. Dokonce zašel až k tomu, že tohoto chování litoval:

Tady se mohu jenom omluvit ostatním vývojářům souborových systémech za sémantiku data=ordered; v tomto okamžiku lituji, že jsme z data=ordered udělali pro ext3 výchozí volbu. Jenže autoři aplikací nás značně přečíslují a realisticky nebudeme schopni snadno vrátit osm let, kdy si autoři aplikací zvykali na to, že fsync() není nutné a že je u ext3 dokonce nevhodné.

Jediný problém zde je, že ne všichni souhlasí s tím, že chování ext3 je špatné - alespoň, co se robustnosti týče. Většina této větve diskuze pokrývala stejné záležitosti jako článek na LWN Lepší než POSIX? před několika týdny. Významná část vývojářů nechce, aby větší robustnost poskytovaná režimem data=ordered zmizela. Matthew Garret tento postoj dobře objasnil:

Ty ale stále argumentuješ tím, že aplikace by měly začít používat fsync(). Já říkám, že nejenom že je to zbytečné (většina kódu nikdy "opravena" nebude), ale také je to krok zpátky. Ve většině případů aplikace nepotřebují garance, které poskytuje fsync(), a vzhledem k tomu, že chceme, aby lidé používali ext3 i budoucích letech, také nepotřebují postih výkonnosti, který fsync() přináší. Souborové systémy by měly prostě dělat správnou věc místo toho, aby ztrácely data uživatelů a pak tvrdily, že je to v pořádku, protože POSIX říká, že se to smí.

Jedna z možností, která se objevila, bylo rozšířit POSIX novým systémovým voláním (nazvaným nějak jako fbarrier()), které by vynutilo řazení operací souborového systému. Volání fbarrier() by například mohlo vyvolat zápis dat na disk pro nové soubory předtím, než by takový soubor bylo možné přejmenovat místo jiného. Pro někoho byl tento nápad přitažlivý, ale Linusovi se nelíbí:

Každý, kdo chce složitější a delikátnější rozhraní pro souborové systémy, je blázen. Nejenom že by se nepoužívala, ale rozhodně by nikdy nebyla stabilní.

Takže místo vytváření bariér, které nikdo nebude používat, by se lidé od souborových systémů měli zaměřit na to, aby "špatně napsaný" kód "prostě fungoval", pokud někdo nebude mít opravdu smůlu. Protože, ať už se vám to líbí nebo ne, platí to pro 99 % kódu.

relatime

Mezitím jiná větev konverzace znovu řešila staré téma: aktualizace atime. Souborové systémy unixového stylu tradičně sledují čas, kdy se k souboru naposledy přistupovalo ("atime"), i když ve skutečnosti tato informace nemá mnoho využití. Sledování atime je problém pro výkonnost, protože z každé operace čtení se tím zároveň stává i operace zápisu. Z toho důvodu má Linux již dlouho připojovací volbu "noatime", která vypíná aktualizace atime na daném souborovém systému.

Jak se tak stává, úplné zakázání aktualizace atime může znamenat problémy. Jedním z nich je, že mail klient mutt používá atime k tomu, aby zjistil, jestli je ve schránce (mailbox) nová pošta. Jestliže je čas posledního přístupu před časem poslední modifikace, pak mutt ví, že do takové schránky byl doručen e-mail od doby, kdy ji vlastník naposledy prohlížel. Zakázání atime tento mechanismus rozbije. V reakci na tento problém byla do jádra přidána volba "relatime", která způsobuje, že atime se aktualizuje, pouze pokud je předchozí hodnota starší než čas modifikace. Díky volbě relatime mutt funguje, ale ukazuje se, že to stále není dost: některé distribuce mají programy pro pročišťování dočasných adresářů, které smažou cokoliv, co se dostatečně dlouhou dobu nepoužívalo. S relatime mohou soubory vypadat zcela nepoužívané, i když se z nich často čte.

Pokud by se podařilo relatime zprovoznit, výhody by mohly být významné; vypnutí aktualizací atime může odstranit spoustu zápisů na disk. To následně sníží latence ve prospěch užitečnějšího provozu a konečně také pomůže vyhnout se roztáčení disků u laptopů. Za tímto účelem Matthew Garret zaslal patch, který nepatrně modifikuje sémantiku relatime: umožní aktualizaci atime, pokud je předchozí hodnota více než den stará. Tento přístup odstraňuje většinu aktualizací atime, ale hodnota je i tak téměř aktuální.

Patch byl navržen k začlenění a co víc: padl návrh, aby relatime bylo výchozí nastavení pro souborové systémy připojené v Linuxu. Každý, kdo by chtěl tradiční chování atime, by musel svůj souborový systém připojit s novou připojovací volbou "strictatime". Tento nápad z několika důvodů narazil na okamžitou opozici. Andrewu Mortonovi se nelíbila napevno nastavená hodnota 24 hodin s tím, že by pro interval mezi aktualizacemi měla být připojovací volba. Tuto volbu by bylo jednoduché implementovat, ale jenom pár lidí si myslí, že je k tomu důvod; je těžké představit si případ, kdy by byla potřeba možnost měnit granularitu aktualizací atime.

Alan Cox namítal, že patch představuje změnu ABI a porušuje standardy. Pokusil se patch stopnout s tím, že takovouto změnu by měli dělat distributoři. Linus nicméně řekl, že je mu to fuk; změna relatime a volba strictatime byly první dvě věci, které začlenil, když se otevřelo začleňovací okno 2.6.30. Jeho postoj byl, že distributoři měli na tuto změnu více než rok a nic neudělali. Nejlepší tedy, říká, je změnit výchozí nastavení v jádře a nechat lidi používat strictatime, pokud opravdu takové chování potřebují.

Pokud by někdo měl zájem, Valerie Aurora napsala detailní článek o této změně. Nemyslí si, že patch přežije v současné podobě; autor tohoto článku na druhou stranu v tomto okamžiku nevidí příliš velký tlak na změnu.

I/O bariéry

Řekněme, že jsme pečliví vývojáři aplikací, kteří správně programují volání fsync() tam, kde je to potřeba. Můžeme si potom myslet, že jsme chráněni proti ztrátě dat v případě pádu. Stále je zde ale potenciální problém: disková mechanika může lhát o tom, že data jsou zapsána na trvalém úložišti. Současný hardware agresivně cachuje operace, aby se zlepšila výkonnost; toto cachování umožní systému pracovat rychleji, ale za cenu přidání dalšího způsobu, jakým se mohou ztratit data.

Samozřejmě je zde způsob, jak disku říci, aby data skutečně zapsal. Bloková vrstva má již dlouho podporu pro bariérové operace, které způsobí, že se data zapíší na disk předtím, než lze spustit další operace. Souborový systém ext3 nicméně ve výchozím nastavení bariéry nepoužívá, protože to znamená postih výkonnosti. Ext4 je má naopak ve výchozím nastavení zapnuté.

Jeff Garzik upozornil na s tím spojený problém: Volání fsync() nutně nemusí zajistit, že disk zapíše data na fyzické médium. Navrhl, že fsync() by mělo vytvořit bariéru, i když je souborový systém jako celek nepoužívá. Tímto způsobem by fsync() mohl plnit to, co slibuje vývojářům aplikací.

Tento nápad není kontroverzní, i když lidé jako takoví se cachemi disků zabývají jenom málo. Tyto cache bývají krátkodobé a dost pravděpodobně se zapíší, i když operační systém spadne nebo některá z komponent systému selže. Šance, že dojde ke ztrátě dat, je tedy na této úrovni mnohem nižší, než když jsou data v cache operačního systému. I tak je ale možné poskytnout garance na vyšší úrovni, takže Fernando Luis Vazquez Cao zaslal sérii patchů, které přidávají bariéry do volání fsync(). A v tu chvíli začaly problémy.

Základní neshodou se zde stalo to, co se má stát, když selže pokus vyslat zařízení operaci na vyprázdnění cache [flush]. Fernandův patch vrací volajícímu chybu ENOTSUPP, ale Linus žádal, aby toto bylo odstraněno. Jeho postoj je takový, že není nic, co by volající mohl se selháním bariérové operace udělat, takže není důvod tuto chybu postupovat výše. Systém by maximálně mohl nastavit příznak, že zařízení bariéry nepodporuje. Jak ale Linus říká, souborové systémy by měly umět žít s tím, co úložné zařízení nabízí.

Na druhou stranu Ric Wheeler tvrdí, že souborové systémy by měly vědět o tom, že bariérové operace nefungují, aby mohly odpovídajícím způsobem zareagovat. Jeho slova:

Jednou z věcí, kterou by mohl volající udělat, je zakázat zápisovou cache pro zařízení. Další by bylo přestat používat transakce - vynechat žurnál, vrátit se k režimu ext2 nebo k něčemu, jako jsou měkké aktualizace [soft update] v BSD.

Zjednodušeně by to souborovému systému dalo na vědomí, že stavební bloky integrity dat ve skutečnosti nejsou, a umožnilo mu to tak (pokud ho to zajímá) zkusit minimalizovat riziko ztráty dat.

Alan Cox do diskuze také vstoupil s podporou silnějších bariér:

Odhodit něco a doufat, že to bloková vrstva nějak udělá, není pro vážné podnikové nasazení dobrý model; a kdyby lidé pochopili nejhorší možné případy, i pro spoustu nepodnikového nasazení.

Zdá se ale, že Linuse tyto argumenty nepřesvědčily. Podle něj by měly souborové systémy dělat, co umí, a přijmout, co jim může nabídnou zařízení pod nimi. V době psaní tohoto článku nebyly do hlavní řady začleněny žádné patche, které do fsync() přidávají bariéry.

K tomu se vztahuje i koncept režimu laptopu. Bylo navrženo, že když je systém v režimu laptopu, volání fsync() by ve skutečnosti nemělo zapisovat data na disk; zapisování by způsobilo roztáčení disku, což by narušovalo záměr tohoto režimu. Reakce na požadavky na I/O bariéry by pravděpodobně byla podobná. Někteří vývojáři nicméně této myšlence oponují s tím, že to oslabuje sliby, které poskytuje API. Zdá se, že toto téma může ještě nějakou dobu pokračovat bez skutečného řešení.

Ladění výkonu

Nakonec se mluvilo o snaze pokusit se, aby se subsystém virtuální paměti choval obecně lépe. Část problému je již nějaký čas známa: Velikosti pamětí vzrostly více než rychlosti disků. Zapsat na disk celý náklad špinavých stránek tedy trvá déle než v minulosti. Tato jednoduchá vlastnost je částí důvodu, proč operace zapisování všeho může trvat dlouhou dobu; prostě nějaký čas trvá, než se na disk přenesou gigabyty dat. Obecně se očekává, že disky bez rotujících částí [solid state disks] tento problém vyřeší, ale také se očekává, že bude ještě nějakou dobu trvat, než budou tyto disky univerzálně používány.

Mezitím se lze pokusit zlepšit výkonnost tím, že se systému nedovolí naakumulovat tolik dat, která je potřeba zapsat. Místo toho, aby špinavé stránky mohly v cache zůstávat po (řekněme) 30 sekund, měly by být zapisovány častěji. Nebo by bylo možné změnit podíl RAM, která obsahuje špinavé stránky, možná v závislosti na pozorování skutečné propustnosti úložných zařízení. Jádro již má limit "špinavých procent", ale někteří vývojáři navrhují, že místo toho by měl být stanoven pevný počet bytů. Konkrétně že by to měl být takový počet bytů, který je úložné zařízení schopno přijmout za (řekněme) jednu sekundu.

Nikdo nemá námitky proti lépe vyladěnému subsystému virtuální paměti. Jsou zde ale skutečné rozepře o tom, jak toto vyladění udělat. Někteří vývojáři navrhují zavést ladící ovládací prvky pro uživatelský prostor a nechat distributory hodnoty vymyslet. Andrew je velkým zastáncem tohoto přístupu:

Opakovaně jsem sledoval, jak hýbáte s výchozími hodnotami v jádře podle zkušeností z reálného nasazení. To samé by bylo možné snadno udělat v init skriptech v distrech a bylo by to mnohem efektivnější, protože by nebylo zapotřebí nové jádro. To jsou data.

Fakt, že jsme se o něco takového nepokusili (pokud vím), je politováníhodný. Proč každý prostě posedává a čeká na jádro, až se v něm objeví nové hodnoty dvou kouzelných čísel, které mohly být nastaveny pomocí skriptů v uživatelském prostoru?

Námitky proti tomuto přístupu jsou následující: distributoři nemohou tato čísla nastavit správně; ve skutečnosti dokonce ani nemají tendence zkusit je nastavit správně. Správné hodnoty se měnívají mezi jednotlivými jádry, takže má smysl držet je v samotném jádře. A jádro by mělo být schopné tyto věci udělat dobře, pokud dělá svou práci. Je zbytečné říkat, že Linus souhlasí s tímto přístupem a říká:

Měli bychom se zaměřit na to udělat to správně. "Uživatelský prostor může ladit, jaké číslo chce" je VŽDY ŠPATNÁ ODPOVĚĎ. Je to zbavení se zodpovědnosti a co je důležitější, je to zbavení se zodpovědnosti, které nepřináší výsledek; výsledkem je pouze to, že každý má jiné nastavení. Pak není šťastný nikdo.

Linus navrhl (ale neimplementoval) jednu sadu heuristik, které by systému umožnily se vyladit. Neil Brown také navrhl přístup založený na měření současného chování úložných zařízení v systému. Opravit věci na této úrovni pravděpodobně zabere nějaký čas; jako všechny změny ve virtuální paměti. Několik inteligentních lidí ale začíná o problému přemýšlet a to je důležitý první krok.

To lze říct o této diskuzi jako celku. Souborové systémy a I/O zjevně obklopuje mnoho problémů, které vyplavaly na povrch a je potřeba o nich mluvit. Komunita okolo linuxového jádra jako celek by měla přemýšlet o druzích garancí (jak pro robustnost, tak pro výkonnost), které nabídnout uživatelům, a jak tyto garance dodržet. 2009 Linux Storage & Filesystems Workshop začíná 6. dubna; pravděpodobně tam bude diskutováno mnoho z těchto témat. Autorovi článku se podařilo prokecat se na tuto akci, takže zůstaňte na příjmu.

       

Komentáře

[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