Fórum Root.cz
Hlavní témata => Server => Téma založeno: hazardrok 03. 01. 2022, 12:05:49
-
Ahoj, provozuju dva servery s ubuntu. Jeden mám fyzicky a druhej používá VPS. Na obou serverech jede stejnej software. Ten fyzizkej používám pro ladění a vývoj a na tom VPS provozuju finální aplikaci. Jen poznámka, že vše provozuju dost amatérsky a nejsem úplně IT odborník.
Poslední dobou se mi na tom VPS začlo dít, že mi začla růst hodnota buff/cache z výpisu htop. Roste v podstatě až do maxima než server spadne. Na tom fyzickém stroji se to neděje což je pro mě záhada, ale to mi zas tak nevadí.
Chtěl bych se tedy zeptat co to vlastně to buff/cache je? Zkoušel jsem porovnávat dva různé záznamy z výstupu htop před a po nárůstu buff/cache a snažil se najít v které aplikaci paměť je, ale došel jsem k závěru že žádná spuštěná aplikace tuto paměť nepoužívá. Nebo jsem to nenašel.
Pak jsem narazil na tento odkaz:
https://www.geeksforgeeks.org/how-to-clear-ram-memory-cache-buffer-and-swap-space-on-linux/ (https://www.geeksforgeeks.org/how-to-clear-ram-memory-cache-buffer-and-swap-space-on-linux/)
Když jsem provedl to co tam popisujou paměť se skutečně uvolnila a serveru se ulehčilo. Píšou tam také, že se to provádí každé tři hodiny. Chci se tedy ještě zeptat, jestli návod v tomto odkazu je správná cesta ke stabilitě serveru.
Dík
-
Palec nahoru za dotaz a za používání šedé kůry :-)
Ano správně, to téma je kontroverzní.
Vedle hodnot Buffers/Cached jsou zajímavé také hodnoty MemTotal/MemFree/MemAvailable, Dirty/Writeback, SwapTotal/SwapFree a další. V zásadě je zajímavá velká část obsahu /proc/meminfo, a jeho vývoj v čase.
Odpojit swapáč za jízdy na serveru, který začíná drhnout, mi přijde jako poněkud kaskadérský nápad :-) Zejména bez mrknutí do /proc/meminfo, kolik je naswapováno.
Free_caches způsobí:
- zahození obsahu stránek, který zůstal v ramce ve smyslu "čtecí cache". Tzn pokud něco z toho bude zanedlouho potřeba, vyvolá to nějaký ten přístup k disku navíc = zdržení.
- nejsem si jistý (nepoužívám to) zda způsobí také flushnutí dirty stránek (write-back cache). Pokud to navíc provede "bariérovou operaci", může to způsobit dost dlouhé zdržení. Záleží jaký objem stránek je ve stavu dirty/writeback, kolik je to transakcí, jak rychlé jsou disky a jakou další zátěž ten storage táhne (pokud je sdílený více hostitelskými stroji).
Objem Cached/Buffers sám o sobě mnoho neříká. Stránky "buffered" (čtecí cache) jsou teoreticky "obratem k dispozici" (téměř free), prostě se jenom vyřadí z cache. Tzn. "uvolnit je násilím" by samo o sobě nemělo mít velký přínos. Je možné, že to má vedlejší efekty a konotace. Četl jsem něco o interakci NFS a vespod ZFS, kde free_caches řeší reálný problém. Nebo že konkrétně ve virtualizovaných prostředích to má taky svůj dobrý smysl - cca aby guesti zbytečně nedrželi hostiteli alokovanou fyzickou RAM na nějaké svoje poviderní čtecí cache, "jenom proto že je ta RAMka k dispozici". Protože ve virtualizaci se fyzická RAMka přiděluje vlastně "nadvakrát" - probíhá memory management v rámci hostitele a následně v rámci jednotlivých guestů, tato dvě patra mohou spolupracovat. Padla v této souvislosti taky na okraj zmínka o ballooning driveru (asi jakožto o alternativním způsobu, jak nutit guestův kernel ke střídmému zacházení s využíváním RAMky).
Téma do jisté míry souvisí s fragmentací RAM - té se dá bránit explicitním spuštěním "defragmentace RAM":
echo 1 > /proc/sys/vm/compact_memory
...což ale zřejmě neřeší konkrétně otázky specifické pro virtualizované prostředí.
Odkazy = rychlým dotazem do Googlu jsem našel k tématu několik výživných debat - řazeno cca sestupně podle relevance:
https://serverfault.com/questions/597115/why-drop-caches-in-linux
https://savvinov.com/2019/10/14/memory-fragmentation-the-silent-performance-killer/
https://www.unix.com/unix-for-advanced-and-expert-users/248922-memory-fragmentation-linux-settop-box.html
https://lwn.net/Articles/368869/
-
Díky za reakci a za odkazy. Kontroverzní to asi je, soudě podle jednoho jediného komentáře k problému. Snažil jsem se odkazy pročíst a trochu tomu porozumět, jedno z toho se mi povedlo, ale o úspěšnosti toho druhého dost pochybuji :-D
Po načerpání nových teoretických poznatků mi došlo, že jsem možná zapomněl napsat parametry toho VPS:
2GB RAM, 20GB SSD DISK, 1 CPU Core
Také jsem napsal špatně, že ten server se po vyčerpání paměti zhroutí. To vlastně není pravda, stane se to, že výkon CPU jde na 100%. Provozovatel VPS v mém případě neumožňuje dlouhodobé vytížení VPS a tak ho vypne.
Pokud to správně chápu tak problém je v tom, že se jedná o VPS o jehož konfiguraci nic nevím a asi s ní nic neudělám viz citace od savvinov:In many cases, memory fragmentation can be reduced by tweaking VM parameters. Of course, as with any low-level change, you really need to know what you are doing, so it’s best to get a consult from a Linux expert, or from Oracle support in an SR (and do some good testing).
Třeba to nikam nepovede, ale budu pokračovat v laborování...
Provedl jsem opakovaně:
free -h total used free shared buff/cache available
Mem: 1.9Gi 201Mi 994Mi 2.0Mi 791Mi 1.6Gi
Swap: 2.3Gi 0B 2.3Gi
1. Hodnota Swap je stále na nule a nikdy jsem neviděl, že by se pohnula. Zdá se, že tento prostor se vůbec nepoužívá.
2. buff/cache postupně pomalu v čase roste.
Snažím se stále pochopit jak bych tomu mohl pomoci jinak než nějakým násilným způsobem za jaký je možná považováno echo 3 > /proc/sys/vm/drop_caches, ale nic jiného mě v tuhle chvíli nenapadá, protože mi to příjde, že to není věcí programů, které používám, ale věcí systému který rozhodně nemám plně pod svou kontrolou.
-
drop_caches asi moc nevadí, jedině to může trochu škodit diskovému výkonu. Pokud se to bude dělat jednou za 3 hodiny, tak to nebude tak strašné. Možná by stačilo ještě míň často? Taky jde místo nejdrsnějšího 3 zapsat do drop_caches jen 2 nebo 1, což by možná účel také splnilo, ale negativní efekt by byl menší.
Taky je možnost snížit prioritu cache pomocí velké hodnoty vfs_cache_pressure, defaultní je 100, ale funguje to jen ve spojitosti se swapem, tak bych asi zároveň zvýšil swappiness a asi by se vyplatilo snížit a zafixovat vm.dirty_bytes a vm.dirty_background_bytes. Defaultně je to hodně, nějaké procento celkové paměti.
něco jako toto v /etc/sysctl.conf
vm.vfs_cache_pressure=500
vm.swappiness=100
vm.dirty_bytes=16638608
vm.dirty_background_bytes=8319304
Ještě mě napadlo, jestli nemáte nějaké hugepages? je z výstupu něco nenulové?
cat /sys/kernel/mm/hugepages/hugepages-*/nr_hugepages
-
Dafaultně je dirty_bytes 20% a dirty_background_bytes 10% RAM, tedy ve vašem případě 410GB a 205GB. Já to zmenšil na 16GB a 8GB.
-
V tomto kontextu je VM configuration konfigurace virtualni pameti. Ne virtualniho stroje.
-
vm.vfs_cache_pressure=500
vm.swappiness=100
vm.dirty_bytes=16638608
vm.dirty_background_bytes=8319304
Našel jsem ještě tenhle odkaz kde se ty parametry vysvětlujou takže aspoň člověk má trochu povědomí co nastavuje: https://letsfoss.com/managing-swap-memory-in-ubuntu/ (https://letsfoss.com/managing-swap-memory-in-ubuntu/)
Tam jsou ty hodnoty trošku v rozporu s tím co píšeš. Takže s těmi hodnotami budu experimentovat.
Zjistil jsem, že jak vm.dirty_bytes, tak vm.dirty_background_bytes jsou v mé konfiguraci nulové takže je nechám na nule.
cat /sys/kernel/mm/hugepages/hugepages-*/nr_hugepagesse provedlo s nulovým výsledkem.
Teď nezbývá než čekat...trvá to cca týden než to zbuchne.
-
Dokud je nějaká paměť "available", tak by neměl být problém. Možná to s pamětí vůbec nesouvisí.
V momentě kdy ten stroj sežere 100% CPU, dá se zjistit, čím je procesor konkrétně vytížený?
Mimochodem popis problému mi cosi připomněl (https://lists.nongnu.org/archive/html/qemu-discuss/2021-12/msg00085.html), ale asi je to podobnost čistě náhodná.
-
V momentě kdy ten stroj sežere 100% CPU, dá se zjistit, čím je procesor konkrétně vytížený?
Na tomhle teď pracuju, takže bych to snad měl vědět příští cyklus zhroucení pokud se to povede zachytit. Napsal jsem si pro to krásnej a asi dost úchylnej script kterej se spouští každou minutu :-)
#!/bin/bash
for i in {1..19}
do
currentDate=`date +"%Y-%m-%d_%T"`
currentMoon=`date +"%m"`
currentDay=`date +"%d"`
mkdir -p /home/irma/MONITOR/$currentMoon/$currentDay
#echo $currentTime
top -b -n 1 > /home/irma/MONITOR/$currentMoon/$currentDay/$currentDate
gzip /home/irma/MONITOR/$currentMoon/$currentDay/$currentDate
sleep 3
done
Možná to nebude fungovat, ale nic lepšího co mi nezabralo moc času na napsání mě nenapadlo.
-
Napsal jsem si pro to krásnej a asi dost úchylnej script
→ sysstat aka sar?
> currentMoon=`date +"%m"`
mhmmmmmm :)
-
Našel jsem ještě tenhle odkaz kde se ty parametry vysvětlujou takže aspoň člověk má trochu povědomí co nastavuje: https://letsfoss.com/managing-swap-memory-in-ubuntu/ (https://letsfoss.com/managing-swap-memory-in-ubuntu/)
Tam jsou ty hodnoty trošku v rozporu s tím co píšeš. Takže s těmi hodnotami budu experimentovat.
ano, protože většina uživatelů chce malý swap a velký cache, což pomáhá IO výkonu a na desktopu jsou malé zádrhy kvůli disku dost poznat
Zjistil jsem, že jak vm.dirty_bytes, tak vm.dirty_background_bytes jsou v mé konfiguraci nulové takže je nechám na nule.
To tak je, protože vm.drity_ratio=20 a vm.dirty_background_ratio=10. Když se zapíše do _bytes, tak se zase vynuluje _ratio
Jinak je možné, že to opravdu s cache nesouvisí. To, že cache naroste na celou dostupnou RAM se prostě časem stane, ale není to nic špatného. Cache se může lehce zapsat a zahodit. Leda by opravdu drop_cache dlouhodobě problém řešil.
Jinak špinavým řešením by také mohl být restart každé třeba 4 dny. Pokud problém nastane za týdden.
-
Co žere to 100%CPU? Ve virtualboxu s Win10 běžícím nad Mintem se mi při něčem větším ve Win rozjede kernelí vlákno kcompactd0 na 100% jádra a virtuál se takřka zastaví. Někdy to trvá minuty, někdy musím rebootnout a pustit vmware jako první, než na linuxu spustím něco většího (něco jako aby měl vmware souvislou paměť). Win10 10GB, hostitel celkem 16GB. Řekl bych, že to dřív nedělalo.
-
Ahoj, nabízím pokračování toho co se tu už řešilo, neboť po několika týdnech mám konečně výsledky co se na tom VPS děje. Závěr je to, že ten VPS podle mě pracuje špatně a nevidím chybu u sebe (samozřejmě připouštím, že jsem něco přehlédnul, něčemu neporozumněl, nebo nemám dostatečné znalosti a zkušenosti). Došel jsem k tomu tak, že jsem si každé tři sekundy logoval výsledek z příkazu top. Najednou se ale stane to, že z ničeho nic ten příkaz top přestane pracovat a vrací nulové hodnoty, po několika sekundách chcípne úplně celý systém. Poslední log (ani logy předtím) neukazuje na nic neobvyklého.
Neměl by ještě někdo nějaký nápad na základě těchto nových skutečností?
Výpis posledního top před zhroucením:
top - 09:00:52 up 2 days, 19:35, 0 users, load average: 0.12, 0.08, 0.08
Tasks: 103 total, 1 running, 102 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 6.2 sy, 0.0 ni, 87.5 id, 0.0 wa, 0.0 hi, 6.2 si, 0.0 st
MiB Mem : 1983.4 total, 160.4 free, 216.1 used, 1606.9 buff/cache
MiB Swap: 2355.0 total, 2353.7 free, 1.3 used. 1584.3 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
585042 root 20 0 0 0 0 I 6.7 0.0 0:28.97 kworker+
677495 root 20 0 9120 3584 3140 R 6.7 0.2 0:00.01 top
1 root 20 0 168848 12648 8168 S 0.0 0.6 0:20.57 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.04 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par+
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker+
8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_perc+
9 root 20 0 0 0 0 S 0.0 0.0 3:30.42 ksoftir+
10 root 20 0 0 0 0 I 0.0 0.0 7:57.32 rcu_sch+
11 root rt 0 0 0 0 S 0.0 0.0 0:00.55 migrati+
12 root -51 0 0 0 0 S 0.0 0.0 0:00.00 idle_in+
14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmp+
16 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns
17 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tas+
18 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kauditd
19 root 20 0 0 0 0 S 0.0 0.0 0:00.07 khungta+
20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_rea+
21 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 writeba+
22 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kcompac+
23 root 25 5 0 0 0 S 0.0 0.0 0:00.00 ksmd
24 root 39 19 0 0 0 S 0.0 0.0 0:00.00 khugepa+
70 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kintegr+
71 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kblockd
72 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 blkcg_p+
73 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 tpm_dev+
74 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 ata_sff
75 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 md
76 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 edac-po+
77 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 devfreq+
78 root rt 0 0 0 0 S 0.0 0.0 0:00.00 watchdo+
80 root 20 0 0 0 0 S 0.0 0.0 0:00.59 kswapd0
81 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ecryptf+
83 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kthrotld
84 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 acpi_th+
85 root 20 0 0 0 0 S 0.0 0.0 0:00.00 scsi_eh+
86 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 scsi_tm+
87 root 20 0 0 0 0 S 0.0 0.0 0:00.00 scsi_eh+
88 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 scsi_tm+
90 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 vfio-ir+
92 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 ipv6_ad+
101 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kstrp
104 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker+
118 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 charger+
120 root 0 -20 0 0 0 I 0.0 0.0 0:09.47 kworker+
201 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 raid5wq
252 root 20 0 0 0 0 S 0.0 0.0 0:18.92 jbd2/vd+
253 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 ext4-rs+
329 root 19 -1 96528 45216 43980 S 0.0 2.2 1:46.10 systemd+
358 root 20 0 2488 584 516 S 0.0 0.0 0:00.00 none
371 root 20 0 21288 5256 3932 S 0.0 0.3 0:01.95 systemd+
540 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kaluad
541 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kmpath_+
542 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kmpathd
543 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kmpath_+
544 root rt 0 280208 17992 8200 S 0.0 0.9 0:21.06 multipa+
553 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 loop0
555 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 loop1
557 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 loop2
558 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 loop3
560 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 loop4
563 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 loop5
564 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 loop6
581 systemd+ 20 0 90196 5924 5152 S 0.0 0.3 0:01.50 systemd+
623 systemd+ 20 0 18380 7388 6536 S 0.0 0.4 0:07.47 systemd+
625 systemd+ 20 0 23860 11892 7984 S 0.0 0.6 0:06.79 systemd+
636 root 20 0 236084 7516 6328 S 0.0 0.4 0:24.36 account+
639 root 20 0 6812 2784 2520 S 0.0 0.1 0:03.02 cron
640 message+ 20 0 7828 4632 3688 S 0.0 0.2 0:01.62 dbus-da+
651 root 20 0 29340 15056 7304 S 0.0 0.7 0:01.98 network+
653 root 20 0 10324 5900 4620 S 0.0 0.3 0:21.58 openvpn
654 root 20 0 9692 5236 4532 S 0.0 0.3 0:05.18 openvpn
656 syslog 20 0 224348 4748 3216 S 0.0 0.2 0:16.87 rsyslogd
662 root 20 0 17256 7848 6684 S 0.0 0.4 0:00.78 systemd+
664 daemon 20 0 3792 2100 1924 S 0.0 0.1 0:00.00 atd
714 root 20 0 12176 6512 5584 S 0.0 0.3 0:19.87 sshd
747 root 20 0 5828 1576 1464 S 0.0 0.1 0:00.00 agetty
759 root 20 0 107908 15440 8072 S 0.0 0.8 0:00.12 unatten+
766 irma 20 0 18392 9600 8048 S 0.0 0.5 0:00.16 systemd
771 irma 20 0 103244 3292 0 S 0.0 0.2 0:00.00 (sd-pam)
778 root 20 0 232716 6552 5856 S 0.0 0.3 0:00.05 polkitd
913 irma 20 0 7084 2208 1820 S 0.0 0.1 0:17.21 screen
915 irma 20 0 6952 2052 1792 S 0.0 0.1 0:00.00 screen
917 irma 20 0 6892 2276 2044 S 0.0 0.1 0:00.00 start_b+
918 irma 20 0 7024 2572 2124 S 0.0 0.1 0:00.00 start_m+
919 irma 20 0 10352 2236 1768 S 0.0 0.1 1:44.96 main
169967 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 xfsalloc
169975 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 xfs_mru+
169981 root 20 0 0 0 0 S 0.0 0.0 0:00.00 jfsIO
169982 root 20 0 0 0 0 S 0.0 0.0 0:00.00 jfsComm+
169983 root 20 0 0 0 0 S 0.0 0.0 0:00.00 jfsSync
316561 irma 20 0 333968 31272 7444 S 0.0 1.5 49:55.47 main
416282 root 20 0 725792 42116 19368 S 0.0 2.1 0:07.49 snapd
668599 grafana 20 0 1304764 81720 53960 S 0.0 4.0 0:10.34 grafana+
668777 grafana 20 0 1306740 19128 11268 S 0.0 0.9 0:02.24 gpx_sql+
670932 root 20 0 0 0 0 I 0.0 0.0 0:00.00 kworker+
675275 root 20 0 0 0 0 I 0.0 0.0 0:00.12 kworker+
676194 root 20 0 0 0 0 I 0.0 0.0 0:00.02 kworker+
677044 root 20 0 0 0 0 I 0.0 0.0 0:00.00 kworker+
677294 root 20 0 8352 3284 2612 S 0.0 0.2 0:00.00 cron
677299 root 20 0 2608 612 540 S 0.0 0.0 0:00.00 sh
677303 root 20 0 6892 3184 2940 S 0.0 0.2 0:00.03 system_+
Printscreen seznamu logů v příloze.
-
Mozno trepnem blbost, ale nie je tam nejak vela uspanych threadov a moc malo beziacich? aka 1 running, 102 sleeping.
Plus su tam nejake loop procesy:
553 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 loop0
555 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 loop1
557 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 loop2
558 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 loop3
560 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 loop4
563 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 loop5
564 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 loop6
Co su to za procesy? Nie su to nahodou nejake interne cykly z: ...
ktore sa vymkly kontrole?
-
Díky za reakci. Ta tvoje trepnutá blbost mě navedla akorád na to, že vůbec netuším co většina těch procesů znamená. Pokud bych se zabejval těma co se jmenujou loopx tak pokud správně rozumím číslům PID tak se spustí dřív než je vůbec předáno řízení auživatelským programům. Z toho bych si tedy myslel, že je to součástí systému. Na tom stroji není ani nic extra nainstalováno...jen SSH, VPN, grafana. Pak tam běží pár mých procesů kdy některé jen kopírují data a jiné komunikujou s TCP a ukládají do databáze (SQlite). Když to stejné běží na fyzickém stroji žádný problémy nejsou.
Ono je to ale ve finále všechno jedno, jediné co se děje že poskytovatel VPN odstaví ten virtuální stoj a pošle mail. Já ho nastartuju a jede se dál. Celej ten projekt je čistě amatérskej a stejně tak k tomu přistupujou všichni uživatelé, takže to nikoho neuráží....jen mě :-D
-
Trosku som poguuglil a tie loop procesy by mali byt nejake mountnute veci
https://en.wikipedia.org/wiki/Loop_device
a zrejme to teda vytvara pre kazdy mountnuty priecinok/disk vlastny proces (ak sa mylim opravte ma niekto, moje vedomosti o mountovani zacinaju otvorenim googlu a koncia stlacenim enteru).
Mohol som si to pozriet uz predtym a netrepnut blbost :)
-
...se spustí dřív než je vůbec předáno řízení...
...se spustí dřív než je vůbec předáno řízení...
menuentry "Tinycore ISO" {
loopback loop /tinycore.iso
linux (loop)/boot/bzImage --
initrd (loop)/boot/tinycore.gz
}
to platí ale byl by to absurdní důvod