74
« kdy: 01. 01. 2023, 09:17:09 »
Build na tmpfs je IMHO většinou zbytečný, zejména v době NVMe SSD. Ano, budou specifické případy (teď mě napadají testy se skutečnou DB, byť tam bývají i jiná řešení jako vypnutí fsync), kdy se to hodí. Jinak ale:
* Načtení zdrojáků bude asi rychlé, byť latence bude stále vyšší než z RAM. Když bych to chtěl řešit, mohu hodit zdrojáky do cache tím, že je načtu (něco jako find -type f -print0 -execute cat > /dev/null). To můžeme udělat i pro některé soubory knihoven, které máme v jiném adresáři.
* Zápis může zdržovat fsync, pokud na něm kompilátor trvá. (Nemám moc přehled, jak moc to řeší který kompilátor.) Kdybych to chtěl řešit, mohu použít něco jako eatmydata, akorát musím dát pozor na zápisy mimo build dir (například udělat cargo fetch předem). Po buildu se hodí spustit sync, aby se vše zapsalo. Pokud nevydrží (výpadek proudu, kernel panic, …), může se hodit čistý build.
* V principu totiž kernel umí pracovat s RAM místo fyzického úložiště celkem transparentně. Něco může vyřešit sám (např. opakované čtení) naprosto automaticky, někdy to může chtít napovědět, co má udělat předem (číst všechny soubory z jednoho adresáře; lze dělat i paralelně po zapnutí buildu), někdy je potřeba říct, co si může dovolit (eatmydata, permisivní mount options jako data=writeback a další).
V době HDD to s dostatečnou RAM asi mělo celkem smysl. S rychlými SSD sice věřím, že takové případy najdete, ale zároveň často to IMHO bude zbytečná práce, a čtení+zápis (tj. kopírování do/z tmpfs) nemůže probíhat paralelně s buildem.
Pokud máte po ruce nějaký veřejný projekt, kde si myslíte, že kopírování z a do tmpfs má smysl, mohu zkusit jednotlivé přístupy změřit. Podmínka je, aby šel snadno buildovat.
Zobrazit příspěvky
