Jaderné noviny – 1. 12. 2016: statx() v3

12. 12. 2016 | Redakce | Jaderné noviny | 3010×

Stav vydání jádra. Citáty týdne: Paul McKenney a Linus Torvalds. statx() v3.

Stav vývoje jádra

Současný vývojový kernel je 4.9-rc7, vydaný 27. listopadu. Linus řekl, že se to pomalu začíná tvarovat a je možné, byť nepravděpodobné, že finální vydání 4.9 připadne na 4. prosince. „Prostě si vyhrazuji právo rozhodnout se příští víkend.“

Verze 4.9-rc6 byla vydána 20. listopadu.

Seznam regresí v cyklu 4.9, zveřejněný 20. listopadu, obsahoval deset otevřených problémů.

Stabilní aktualizace: Za poslední dva týdny jsme se dočkali vydání 4.8.9 a 4.4.33 (19. listopadu), 4.8.10 a 4.4.34 (21. listopadu) a 4.8.11 a 4.4.35 (26. listopadu). Jako by to nestačilo, verze 4.8.12 a 4.4.36 byly v době psaní článku v procesu revidování a vyšly 2. prosince.

Citáty týdne

Vzhledem k historii RCU jsem zjevně nepoctivý praktik. Přesto se domnívám, že pro běžnou práci je poctivost tou nejlepší zásadou. Ale když jde do tuhého, robustní kombinace nepoctivosti a neortodoxnosti často bývá jedinou cestou vpřed.

– Paul McKenney

Tajně jsme nahradili jejich normální MODVERSIONS vůbec ničím. Schválně, jestli si toho všimnou.

– Linus Torvalds

statx() v3

Některé změny si občas vyžádají mnoho času, než můžeme sklízet jejich plody. Přesně to se ukázalo jako případ navrhovaného systémového volání statx(). Tedy aspoň pokud jde o tu část „mnoho času“, protože na „sklizeň“ stále čekáme. Podle všech všeho se ovšem dokončení tohoto rozšíření systémového volání stat() docela blíží. Nedávné patche ukazují současný stav statx() a také co stále drhne.

Systémové volání stat(), které vrací metadata o souboru, má dlouholetou historii. Poprvé se objevilo v prvním vydání Unixu v roce 1971. V následujících 45 letech se změnilo jen malinko, ačkoliv se proměnil zbytek operačního systému okolo. Takže asi není překvapující, že stat() často nevyhovuje dnešním požadavkům. Nedokáže reprezentovat většinu aktuálně relevantních informací o souborech, namátkou číslo verze, čas vytvoření, stav šifrování nebo třeba zda je soubor uložený na vzdáleném úložišti. Volající nemá možnost vybrat si informace, o které má zájem, čímž si může vynutit nákladné operace sbírající data, která aplikace zrovna nepotřebuje. Pole časových razítek trpí problémem roku 2038. A tak by se dalo pokračovat.

David Howells od roku 2010 příležitostně pracuje na náhradě stat(). Jeho třetí verze patche (počítáno od chvíle, kdy počátkem letošního roku opět zapojil úsilí) vyšla 23. listopadu. Přestože se navrhovaný statx() podobá verzi z května, došlo k několika změnám.

Prototyp statx() stále vypadá takto:

int statx(int dfd, const char *filename, unsigned atflag, unsigned mask,
          struct statx *buffer);

Normálně je dfd popisovačem souboru (file descriptor), který identifikuje adresář, a filename je jméno požadovaného souboru. Očekává se, že se soubor bude nacházet v relativní cestě vůči danému adresáři. Jestliže se ve filename předá NULL, pak se dfd vykládá jako přímý odkaz na požadovaný soubor. Takže statx() nahrazuje funkci jak stat(), tak i fstat().

Argument atflag upravuje chování systémového volání. Zachází s několika příznaky, které se v současných jádrech už vyskytují: AT_SYMLINK_NOFOLLOW vede k vrácení informací o symbolickém odkazu, místo aby byl odkaz následován, a AT_NO_AUTOMOUNT brání automatickému připojení vzdálených souborových systémů. Skupina nových příznaků vyhrazených pro statx() řídí synchronizaci dat se vzdálenými servery, což umožňuje aplikacím nastavit poměr mezi aktivitou I/O a přesnými výsledky. AT_STATX_FORCE_SYNC vynutí synchronizaci se vzdáleným serverem i v případě, že si lokální jádro myslí, že má aktuální informace, zatímco AT_STATX_DONT_SYNC blokuje dotazy na vzdálený server, čímž si získá rychlé výsledky, které však mohou být neaktuální nebo zcela nedostupné.

Parametr atflag potom určuje, jak statx() získá data. Další parametr, mask, se zase stará o to, která data mají být získána. Dostupné příznaky aplikaci umožňují vyžádat si oprávnění k souboru, typ, počet odkazů, vlastnictví, časová razítka atd. Speciální hodnota STATX_BASIC_STATS odpovídá všemu, co by vracel stat(), zatímco STAT_ALL vrací úplně vše, co je k dispozici. Snížení objemu požadovaných informací by mohlo snížit množství I/O operací nutných k vykonání systémového volání. Někteří se ale obávají, že vývojáři prostě použijí STATX_ALL, aby o tom nemuseli přemýšlet.

Poslední argument, buffer, obsahuje strukturu, která se naplní relevantními informacemi. V této verzi patche vypadá následovně:

struct statx {
    __u32	stx_mask;	/* What results were written [uncond] */
    __u32	stx_blksize;	/* Preferred general I/O size [uncond] */
    __u64	stx_attributes;	/* Flags conveying information about the file [uncond] */
    __u32	stx_nlink;	/* Number of hard links */
    __u32	stx_uid;	/* User ID of owner */
    __u32	stx_gid;	/* Group ID of owner */
    __u16	stx_mode;	/* File mode */
    __u16	__spare0[1];
    __u64	stx_ino;	/* Inode number */
    __u64	stx_size;	/* File size */
    __u64	stx_blocks;	/* Number of 512-byte blocks allocated */
    __u64	__spare1[1];
    struct statx_timestamp	stx_atime;	/* Last access time */
    struct statx_timestamp	stx_btime;	/* File creation time */
    struct statx_timestamp	stx_ctime;	/* Last attribute change time */
    struct statx_timestamp	stx_mtime;	/* Last data modification time */
    __u32	stx_rdev_major;	/* Device ID of special file [if bdev/cdev] */
    __u32	stx_rdev_minor;
    __u32	stx_dev_major;	/* ID of device containing file [uncond] */
    __u32	stx_dev_minor;
    __u64	__spare2[14];	/* Spare space for future expansion */
};

Zde stx_mask indikuje, která pole jsou ve skutečnosti platná. Bude to průnik informací požadovaných aplikací a toho, co souborový systém dokáže poskytnout. stx_attributes obsahuje příznaky popisující stav souboru. Ty indikují, zda je soubor komprimovaný, šifrovaný, neměnný, jen pro přidávání, zda nemá být zahrnut do záloh nebo zda jde o místo pro automatické připojování.

Pole časového razítka obsahují tuto strukturu:

struct statx_timestamp {
    __s64	tv_sec;
    __s32	tv_nsec;
    __s32	__reserved;
};

Pole __reserved bylo přidáno v třetí verzi patche, a to v důsledku jednoho z nejspornějších bodů v nedávných debatách o statx(). Dave Chinner navrhl, že někdy v budoucnu možná nebude rozlišení nanosekundy stačit. Řekl, že rozhraní by mělo být schopné zvládnout femtosekundová časová razítka. Tento názor zastával téměř sám – ostatní účastníci, např. Alan Cox, namítali, že rychlost světla zajistí, že nebudeme nikdy potřebovat časová razítka pod rozlišení jedné nanosekundy. Chinner ale trval na svém, takže Howells přidal pole __reserved s tím, že se může uvést do provozu, pokud to bude v budoucnu potřeba.

Chinner měl celou řadu připomínek ohledně rozhraní, z toho některým doposud nebyla věnována pozornost. Patří mezi ně definice příznaků STATX_ATTR_, které kopírují sadu existujících příznaků používaných s voláními FS_IOC_GETFLAGS a FA_IOC_SETFLAGS ioctl(). Znovupoužívání příznaků umožňuje mikro-optimalizace kódu statx(), ale jak říká Chinner, udržuje se tím několik chyb v rozhraní, které pocházejí s minulosti. Ted Ts'o přišel s podobnou radou, když revidoval verzi tohoto patche z roku 2015, ale současná třetí verze obsahuje stejné definice příznaků.

Největší Chinnerova námitka se týká absence komplexního souboru testů pro statx(). Příslušný kód, řekl, by neměl být začleněn, dokud testy nebudou k dispozici.

Upřímně řečeno, myslím si, že by mělo jít o bezpodmínečný požadavek pro tak generickou a rozšiřitelnou novou funkcionalitu systémového volání. Buď pro ni před začleněním získáme pokrytí testy, nebo k začlenění nedojde. Znovu a znovu mám prokázáno, že věci nefungují, pokud je nemůžeme nejdříve otestovat a široce ověřit nezávislými vývojáři souborových systémů.

Toto stanovisko nedávno zopakovali také další (například Michael Kerrisk). V historii jádra je až příliš mnoho zkušeností se začleňováním nových systémových volání, která nefungují tak, jak bylo inzerováno, což vede k následným bolestem. Howells tyto testy asi nakonec poskytne, ale nebude to tak brzy:

Vzhledem k množství bikesheddingu, který se na tohle téma odehrál, jsem rád, že jsem zatím testovací nástroje *nedělal* – množství práce by to více než zdvojnásobilo. Zatím *stále* nevím, jaká bude výsledná podoba.

Četnost změn v patchi se, zdá se, zpomaluje, takže je možné, že se začíná rýsovat jeho konečná podoba. Historie této práce ale naznačuje, že by nebylo moudré předvídat její začlenění v blízké budoucnosti. Systémové volání stat() je s námi už dlouho, takže je rozumné předpokládat, že statx() vydrží nejméně stejně dlouho. Trocha bikesheddingu navíc, aby rozhraní bylo udělané opravdu správně, se v tomto ohledu zdá být pochopitelná.

       

Komentáře