To neresi zrychleni nahodneho pristupu od nepredikovatelneho uzivatele, ktery prochazi sve uloziste. Vlastne to prochazeni se snazim zrychlit - at uz proto, ze se na to diva clovek netrpelivy, nebo proto, ze chci zkopirovat milion souboru. Bohuzel pri poslednim kopirovani 40TB dat jsem zjistil, jak je to naprd, kdyz hlavicky litaj sem a tam.. protoze pristupujete k datum, ktere nebyly profilovany.
Toto stojí za rozebrání, abychom věděl, že hovoříme o tom samém.
Načtení velkého adresáře trvá dlouho, ale ne vždy za to může filesystem.
1. Je potřeba zkusit ls s parametry, které ho nezdrží. Např. barevný výpis dělá stat na každém souboru. Spoustu času zabere i třídění - takže je potřeba dostat data nejprve unsorted. Je mi jasné, že toto neposune vpřed onoho "nepredikovatelného" uživatele, ale je potřeba vědět, jaký problém ve skutečnosti řešíte.
2. Zkoušel jste na ext4 vobu dir_index?
Chci eliminovat vsechny seeky rotacnich disku, do doby, nez se bude pristupovat k opravdovym datum souboru.
Pro pristup k adresari potrebujete 2 seeky pro kazdou uroven pod-adresaru (cteni directory entry a cteni inode tabulky).
Vypnuti barvicek, trideni, nebo treba locate index, neni to, jak si predstavuji zrychleni prace s FS - spis naopak, chci dosahnout stavu, ze i s temi barvickama a fstat na kazdy souboru, se to provede stejne rychle, jako kdybych pracoval se SSD. fstat nepristupuje k datum souboru, ale jen k inode table, a ano - nez se to natahne, tak to udela zcela zbytecne hromadu seeku.
Resim tedy problem zbytecnych seeku pro lookup metadat. Ackoliv EXT je neco jako distribuovana FAT-ka, takze nemusi sahat vzdy az na kraj disku, tak je tam porad hromada kmitani - v pripade rekurzivniho cteni se delaj 3 seeky pro kazdej soubor, v pripade SSD cache/overlay pro metadata, lze mit pristup na soubor skrze 1 primy seek.
Prakticky tedy tak, aby to byl "sparse mirror" (deravej RAID-1) mezi SSD a HDD, s preferencnim ctenim SSD, kdy to SSD pozadovana data obsahuje (podle bitmapy nebo stromu), s moznosti uzivatelskeho rizeni (editaci bitmapy), co se ma/nema drzet v SSD.
Konkretni ukazka na hdd poli s 29.75M inodama, kdy by na disk nebylo vubec potreba sahnout - vse potrebne by totiz melo byt v te SSD cache:
df -i
IUsed: 29750446
/mnt/files # date; find /mnt/files/ -type d | wc -l; date
Wed Dec 16 10:46:24 AM CET 2020
2664789
Wed Dec 16 12:19:02 PM CET 2020
To nam dela 92m38s = 5558 sec runtime, a fstat s rychlosti 5353 inode/sec.
Pouzita cast inode table dela 3.8 GB (z 62GB moznych) + pro kazdy adresar mame minimalne 4K blok na direntries. Celkove se muselo nacist v nahodnem poradi minimalne 930K inode a 2664K dent bloku. Prenosy na poli jsem videl kolem 1 az 4 MB/s - protoze je to omezeno seekovanim, pocitaje tyto 4K bloky, tak to dela 646 iops/sec (je to R6, 8+2 disky).
slabtop kdyby nekoho zajimalo:
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
3022776 3022770 99% 1.00K 755694 4 3022776K ext4_inode_cache
2499420 2491156 99% 0.19K 119020 21 476080K dentry
3100266 2966827 95% 0.10K 79494 39 317976K buffer_head
322091 322072 99% 0.56K 46013 7 184052K radix_tree_node
32914 32914 100% 3.27K 16457 2 131656K raid6-md3
600796 600778 99% 0.14K 21457 28 85828K ext4_groupinfo_4k
468864 352110 75% 0.04K 4736 99 18944K ext4_extent_status
13286 12690 95% 0.55K 1898 7 7592K inode_cache
Spusteni prikazu samozrejme zacne cist disk znova, protoze v ext4_inode_cache nejsou podrzeny vsechny.. (nemam to ted potunene, pac predesla zkusenost byla, ze dochazela pamet).
Nektere tyto SLAB-y jdou nastavit aby se udrzeli v pameti dele ci vetsi, ale neresi to nahodny pristup po zapnuti - inicializaci nelze provest jinak, nez normalnim ctenim struktury a tudiz nahodnymi pristupy na disk coz trva. A neresi to vubec moznost cachovatelnosti konkretne oznacenych souborovych dat.
Pro srovnani, na ext4 SSD s 1.17M inodama:
# date ; find . -type d | wc -l ; date
Wed Dec 16 12:04:12 PM CET 2020
71649
Wed Dec 16 12:04:34 PM CET 2020
zde tedy fstat jede s rychlosti 53393 inode/sec
Aplikacne specificke pouziti:
Mate treba cDNG videa - 100K souboru v adresari pro kazdej klip, kdyz zanedbame overhead pro samotny adresar, tak v pripade spusteni prehravani (v editoru/barvicim sw), zacne disk kmitat mezi inode table, pripadnou indirect tabulkou a daty souboru. V pripade cachovani vsech urovni pristupovych metadat v SSD, by disk cetl jen video framy.
A ne-posledni ucel: kvuli hromade souboru, ktere se pak povaluji po celem disku, bych rad nektere data sbalil do vnoreneho FS (at uz iso/udf, nebo ext4 image) - treba proto, abych celou vec mohl rychleji - tj. linearnim ctenim - presnutou jinam. A tohle se tim userspace demonem da taky rozparsovat - a pro tyto vnorene FS image nechat nacachovat jejich pristupove udaje.
Zobrazit příspěvky
