Autor Téma: Ubuntu 20.04 -> špatné kopírování na USB flashdisk -> zaseknutí na 99% (Přečteno 3981 krát)

MKeyCZ · « **kdy:** 01 Listopadu 2020, 21:59:52 »

Zdravím, prosím, potřeboval bych poradit s problémem při kopírování souboru z notebooku, kde je nainstalovaný linux ubuntu v.20.04, na USB flashdisk. Problém spočívá v tom, že při kopírování souboru se rychlost kopírování "napálí" na přehnanou rychlost např. 150mb/s poté se kopírování zastaví na 99% a zde se zastaví na dobu cca. 5 minut (záleží na velikosti souboru).

Zjistil jsem, že problém spočívá, co jsem pochopil v cache -> kopírovaný soubor se "rychle natáhne" do RAM paměti (to jest ta velká rychlost) a poté se pomalu přepisuje na požadované externí úložiště.

Zkusil jsem pohledat a zjistil, že problém opraví tento příkaz do terminálu:

Kód: [Vybrat]

sudo sysctl vm.dirty_ratio=10
, co jsem pochopil výše uvedený příkaz způsobí, že cache se rychleji pročistí a soubor se tak uvolní rychleji do požadovaného úložiště. Tudíž jsem hledal dále a zjistil, že je potřeba hodnotu vm.dirty_ratio=10 do souboru /etc/sysctl.conf

, tak jsem spustil můj postup:
1) v terminálu příkaz:

Kód: [Vybrat]

sudo nautilus2) najít si adresář /etc/ v něm požadovaný soubor: sysctl.conf
3) do požadovaného souboru zadat na nový řádek hodnotu:

Kód: [Vybrat]

vm.dirty_ratio=104) uložit a restartovat systém

Bohužel, po restartu ale k mému překvapení se žádná změna nekonala. Kopírování mělo stále stejný problém a hodnota vm.dirty_ratio po kontrole pomocí příkazu v terminále:

Kód: [Vybrat]

sysctl -a | grep dirty zůstala na původní hodnotě 60, což je nežádoucí.

Přitom moje konfigurace souboru sysctl.conf byla úspěšná a hodnota se uložila.

Nevíte, kde jsem mohl udělat chybu? Myslím si, že nejspíše jsem hodnotu vm.dirty_ratio=10 zadal do špatného souboru -> který je správný ? Děkuji

juwa2 · « **Odpověď #1 kdy:** 02 Listopadu 2020, 00:08:16 »

Soubor je správný, nicméně je to v hodnotě wm.dirty_bytes
Projevuje se to jak popisuješ - ukazatel "vyletí" na 99% a pak se zdánlivě neděje nic. Po určité době (dané velikostí kopírovaného souboru a rychlostí flešky) se kopírování dokončí.
Samotná doba kopírování (než se dialog. okno zavře) přitom odpovídá sekvenční rychlosti zápisu flešky, chybný je tedy pouze ten "ukazatel průběhu".
Týká se jenom flešek, extrní HDD jsou OK.
Nicméně je to dosti otravné a zbytečně matoucí.
----------------------------------------------------------------------------------
Náprava je snadná:
Ze souboru

Kód: [Vybrat]

/etc/sysctl.conf

ten tebou přidaný řádek vm.dirty_ratio=10 zase odstraň
A místo něj tam dej řádek

Kód: [Vybrat]

vm.dirty_bytes=15728640
Nezapomeň uložit.
Nakonec (v terminálu) zadej příkaz:

Kód: [Vybrat]

sudo sysctl –p
Pak už můžeš vesele kopírovat....

MKeyCZ · « **Odpověď #2 kdy:** 02 Listopadu 2020, 06:54:47 »

Děkuji, soubor jsem upravil dle vašeho postupu. Bohužel, rychlost kopírování je stále přes 120mb/s a poté tvá než dialog kopírování zmizí.

Mohu hodnotu ještě snížit? Děkuji

Pozn.:
Nevím zda to pomůže, laptop má 8gb RAM

Edit.:
Nyní jsem zkusil hodnotu v souboru sysctl ještě více snížit o polovinu hodnoty kterou jste psal v postupu. Bohužel ani po zadání příkazu sudo sysctl -p a načtení uvedené hodnoty. Se nic nestalo a problém přetrvává. Nevíte čím by to mohlo být způsobeno?

zde je kopie souboru:

Kód: [Vybrat]

#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#

#kernel.domainname = example.com

# Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3

##############################################################3
# Functions previously found in netbase
#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1


###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
#net.ipv4.conf.all.accept_redirects = 0
#net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
#net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
#

###################################################################
# Magic system request Key
# 0=disable, 1=enable all, >1 bitmask of sysrq functions
# See https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
# for what other values do
#kernel.sysrq=438

# added by Insync
fs.inotify.max_user_watches=1048576

vm.dirty_bytes=15728640

juwa2 · « **Odpověď #3 kdy:** 02 Listopadu 2020, 14:01:17 »

Mám taky laptop, taky 8 GB RAM a pomohlo to....
Jak se to chová v live režimu? Stejně?

Zkusils restartovat?
Jestli je hodnota načtená zjistíš příkazem:

Kód: [Vybrat]

sysctl -a | grep dirty
Jinak můžeš studovat
https://superuser.com/questions/1110655/progress-bar-bug-in-linux
https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/

a případně zkusit přidat:

Kód: [Vybrat]

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Je mi známo, že u některých dister se po rebootu nenačítala hodnota wm.dirty_bytes z /etc/sysctl.conf do /proc/sys/vm/dirty_bytes

Takže to ověř. A pokud tomu tak skutečně je, napraví se to přidáním úlohy

Kód: [Vybrat]

@reboot sleep 20 && sudo sysctl -p
do rootovského Cronu a restartovat.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Dále jsem někde četl, že to může souviset se záplatami na meltdown&spectre (já osobně je mám povypínané kvůli výkonu).
Takže můžeš zkusit přidat (do souboru /etc/default/grub) tyto bootovací parametry kernelu:

Kód: [Vybrat]

pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier
Soubor uložit a nakonec restartovat.

MKeyCZ · « **Odpověď #4 kdy:** 02 Listopadu 2020, 14:59:09 »

z terminálu jsem zjistil této hodnoty:

Kód: [Vybrat]

vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 1
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 60000
vm.dirty_ratio = 60
vm.dirty_writeback_centisecs = 60000
vm.dirtytime_expire_seconds = 43200

myslím si, že je problém způsoben jak řikáte tím, že se soubor sysctl.conf nenačte -> zkusil jsem zadat do terminálu příkaz:

Kód: [Vybrat]

@reboot sleep 20 && sudo sysctl -p -> bohužel bez úspěchu.

Kód: [Vybrat]

mkey@LenovoE490:~$ @reboot sleep 20 && sudo sysctl -p

Příkaz „@reboot“ nebyl nalezen, možná jste měli na mysli:

  příkaz „reboot“ z deb balíčku systemd-sysv (245.4-4ubuntu3.2)
  příkaz „reboot“ z deb balíčku molly-guard (0.7.2)

Vyzkoušejte: sudo apt install <název deb balíčku>

- tak nevím zda balíček systemd-sysv instalovat.

Kód: [Vybrat]

pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier - přidání této hodnoty nepomohlo.

juwa2 · « **Odpověď #5 kdy:** 02 Listopadu 2020, 15:34:59 »

Psal jsem "přidat úlohu do rootovského cronu" nikoli zadat ten příkaz do terminálu (kromě toho to není příkaz, ale úloha do cronu).... $:-\$
Takže zadej do terminálu příkaz:

Kód: [Vybrat]

sudo EDITOR=nano crontab -e
Otevře se editor nano s crontabem (viz obrázek) do kterého (na konec) přidáš (zkopíruješ) řádek s tou úlohou
Vložíš ho tam pomocí pravoklik > vložit
V rámci editoru se pohybuj šipkami na klávesnici. Až budeš mít ten řádek vložený, tak
uložit (ctrl+o)
potvrdit (enter)
zavřít nano (ctrl+x)

Jestli je řádek s úlohou přidaný můžeš ověřit příkazem:

Kód: [Vybrat]

sudo crontab -l
Nakonec restartuj PC a ověř zda to pomohlo...

MKeyCZ · « **Odpověď #6 kdy:** 02 Listopadu 2020, 17:21:44 »

, tak už to funguje do souboru sysctl.conf jsem musel přidat příkazy:

Kód: [Vybrat]

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

a poté postupovat dle vašeho postupu aby se soubor načetl. Nyní kopírování funguje, jak má, děkuji

juwa2 · « **Odpověď #7 kdy:** 02 Listopadu 2020, 17:39:38 »

No a bylo potřeba použít tu úlohu do cronu nebo se to načetlo bez ní?

MKeyCZ · « **Odpověď #8 kdy:** 02 Listopadu 2020, 17:46:27 »

musel jsem ji tam zadat. O cronu jsem slyšel poprvé, proto mě to vyvedlo z míry. K čemu vůbec cron slouží? Co jsem pochopil jeho funkce je načítání souborů po restartu systému?

juwa2 · « **Odpověď #9 kdy:** 02 Listopadu 2020, 18:27:30 »

Citace: MKeyCZ 02 Listopadu 2020, 17:46:27

musel jsem ji tam zadat. O cronu jsem slyšel poprvé, proto mě to vyvedlo z míry. K čemu vůbec cron slouží? Co jsem pochopil jeho funkce je načítání souborů po restartu systému?

V kostce:
Cron je standardní nástroj k plánování různých událostí (časovač). Takže když třeba potřebuješ něco spustit/provést v určitý datum/hodinu nebo pravidelně každý den atd. tak použiješ cron. Čas se do něj zadává v tzv. "cron formátu" viz https://crontab.guru/
Crony jsou dva - uživatelský a rootovský. Rootovský musíš použít, pokud potřebuješ spustit úlohu s právy roota, jinak stačí použít ten uživatelský.
Kromě zadání času se používají i některé speciální úlohy, např. ten @reboot použitý tebou
Ten zajistí, že se úloha spustí po restartu.

Úlohy se zadávají do crontabů (něco jako seznam naplánovaných úloh)
Crontaby jsou opět dva - uživatelský a rootovský
Jak se do nich přidávají úlohy už víš....

MKeyCZ · « **Odpověď #10 kdy:** 02 Listopadu 2020, 19:30:09 »

Děkuji moc za vysvětlení s tímto cornem se dají dělat zajímavé věci

Po vypnutí a následného pozdějšího zapnutí laptopu se problém s kopírováním vrátil. Odůvodnil jsem si to tím, že v cronu jsem zadal @reboot -> restart, což se neprovedlo, laptop jsem vypnul. Tudíž jsem do cronu zadal stejný příkaz ale s hodnotou @shutdown -> vypnutí a problém byl opět pryč.

juwa2 · « **Odpověď #11 kdy:** 02 Listopadu 2020, 19:45:31 »

Citace: MKeyCZ 02 Listopadu 2020, 19:30:09

Děkuji moc za vysvětlení s tímto cornem se dají dělat zajímavé věci

Po vypnutí a následného pozdějšího zapnutí laptopu se problém s kopírováním vrátil. Odůvodnil jsem si to tím, že v cronu jsem zadal @reboot -> restart, což se neprovedlo, laptop jsem vypnul. Tudíž jsem do cronu zadal stejný příkaz ale s hodnotou @shutdown -> vypnutí a problém byl opět pryč.

No vidíš - zajímavý poznatek. Protože já například nikdy nevypínám - buď uspávám do RAM nebo občas restartuju když je to kvůli něčemu potřeba.

Otázkou je, jak se to bude chovat po rebootu, pokud tam máš nyní shutdown. Samotného by mě to zajímalo...
Nicméně i kdyby to po rebootu náhodou opět nefungovalo, přidal bys tam ten reboot zpátky.
Takže by tam byly ty úlohy (řádky) dvě (jedna s @reboot a druhá s @shutdown

MKeyCZ · « **Odpověď #12 kdy:** 02 Listopadu 2020, 20:44:18 »

tak bohužel, teď si chvilku hraji se systémem a zjistil jsem následující:
@shutdown sleep 20 && sudo sysctl -p -> nefunguje // příkaz jsem zjistil cron nezná
@reboot sleep 20 && sudo sysctl -p -> funguje, ale má to své "ALE" -- v terminálu se nesmí použít příkaz

Kód: [Vybrat]

shutdown now / či v určitý čas -- nevím proč, ale pokud se tento příkaz v terminálu použije hodnota @reboot se v cornu poté nenačte a problém s kopírováním souboru se objeví znovu a již nepomůže ani opětovné restartování systému, což je zvláštní...

, takže se hodnota

Kód: [Vybrat]

@reboot sleep 20 && sudo sysctl -p v cronu musí uložit znovu, i když se hodnota @reboot v cornu nesmazala (pouze se nenačte a pomůže opětovné uložení...) -> je to velmi zvláštní, nevím proč to tak je.

Příkaz

Kód: [Vybrat]

shutdown v určitý čas -- používám vcelku často

Nemůže být chyba v tom, že po vynutí již má crony problém spustit příkaz přes SUDO?

juwa2 · « **Odpověď #13 kdy:** 02 Listopadu 2020, 21:31:24 »

Zase to "kondáš".....
Parametry pro bootování kernelu do cronu vůbec nepatří!! Proč je tam dáváš? A do Terminálu už vůbec nepatří.
Dávají se do souboru /etc/default/grub (když už teda).

A už ti to přece fungovalo.... $:-\$
Takže v tom rootovském cronu budou tyto dva řádky (viz obrázek):

Kód: [Vybrat]

@reboot sleep 20 && sudo sysctl -p
@shutdown sleep 20 && sudo sysctl -p

A pro jistotu sem dej snímky Terminálů s příkazy

Kód: [Vybrat]

sudo crontab -l
a

Kód: [Vybrat]

crontab -l
Ať je vidět, cos tam "napáchal" za nesmysly....

MKeyCZ · « **Odpověď #14 kdy:** 02 Listopadu 2020, 21:39:11 »

Omlouvám se takto to mám, jak jste psal, špatně jsem zkopíroval text z komentáře zde na foru

Kód: [Vybrat]

# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
# 
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
# 
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
# 
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
# 
# For more information see the manual pages of crontab(5) and cron(8)
# 
# m h  dom mon dow   command

@reboot sleep 20 && sudo sysctl -p
@shutdown sleep 20 && sudo sysctl -p  --> tato hodnota nejde uložit // crontab tuto hodnotu nezná

,

takto to mám jak jste psal. Bohužel, ale jak jsem uvedl chyba se přesto vyskytuje po vypnutí.

poslal jsem i screenshot

juwa2 · « **Odpověď #15 kdy:** 02 Listopadu 2020, 22:12:57 »

Ano, crontab hodnotu (parametr) @shutdown opravdu nezná. Zajímavé je, že je to v rozporu s tím co píšeš výše...
Takže ten jeden řádek odstraň (vlastně už ho tam nemáš). Pak to bude ovšem fungovat jenom po rebootu.
Než příště začneš zadávat naslepo parametry do čehokoli, prostuduj si nejprve manuál k dané aplikaci např.
https://www.root.cz/man/5/crontab/
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Pokud bys chtěl, aby to bylo funkční i po vypnutí, bylo by řešením ten příkaz (sudo sysctl –p) spouštět raději (skriptem) po přihlášení.
Pak by to fungovalo vždycky.
Jelikož ale ten příkaz (skript) vyžaduje práva roota, musel bys ho přidat do výjimek (v sudoers). Není to nic extra složitého.
Obsah skriptu dirty_bit.sh (vytvoř si ho, dej ho třeba do /bin a nastav mu spustitelnost) bude:

Kód: [Vybrat]

#!/bin/bash
sleep 60
sysctl -p

Výjimku pro něj nastavíš - do Terminálu zadej příkaz:

Kód: [Vybrat]

sudo visudo
Otevře se editor nano
Na konec přidej řádek

Kód: [Vybrat]

mkey ALL=NOPASSWD: /bin/dirty_bit.sh

A ulož jako obvykle
ctrl+o
enter
ctrl+x

Přidej si ten skript do "Aplikace spouštěné při přihlášení". Příkaz tedy bude sudo /bin/dirty_bit.sh

Na závěr ještě odstraň z crontabu oba ty řádky.

Pak už to můžeš vyzkoušet (restart i vypnutí)......

MKeyCZ · « **Odpověď #16 kdy:** 03 Listopadu 2020, 07:05:27 »

Tak jsem udělal přesně to jak píšete v postupu, můžete zkontrolovat na screenshotech, ale bohužel při kopírování je stále ta samá chyba.

-> přijde mi, že něco v systému brání načtení daných hodnot, ale netuším co.
-> zkusil jsem upravit Váš skript ještě takto:

Kód: [Vybrat]

#!/bin/bash
sudo sysctl vm.dirty_ratio=3

- příkaz v terminalu jsem zjistil, že mi funguje při vyřešení problému s kopírováním -> zkusím zda se příkaz spustí automaticky po nabootování systému/startu. -> to by problém mohlo také vyřešit.

ani to nepomohlo, hodnoty jsou stále stejné...

Kód: [Vybrat]

vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 1
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 60000
vm.dirty_ratio = 60      -> -> -> tuto hodnotu potřebuji snížit na 3, poté systém dobře ukazuje hodnoty při kopírování
vm.dirty_writeback_centisecs = 60000
vm.dirtytime_expire_seconds = 43200
sysctl: permission denied on key 'vm.stat_refresh'

-> přijde mi, že po startu systému něco(nějaká aplikace, či skript...) vrátí výše uvedené hodnoty zpět..., což je nezádoucí.
-> zkoušel jsem hledat našel jsem jen tuto diskuzi, ale nejsem z toho moc moudrý https://askubuntu.com/questions/566361/cant-change-vm-dirty-ratio-with-etc-sysctl-conf -> skript, který je tu uveden:

Kód: [Vybrat]

/usr/lib/pm-utils/power.d/laptop-mode jsem v systému nenašel. V daném adresáři se nachází pouze soubor: 95hdparm-apm.

Ventero · « **Odpověď #17 kdy:** 03 Listopadu 2020, 11:41:58 »

Tak to zkus ještě jinak - v crontab nic a skript bude mít tento zápis:

Kód: [Vybrat]

#!/bin/bash
sysctl vm.dirty_bytes=15728640       #pokud parametr ma vliv
sysctl vm.dirty_background_ratio = 5 #nebo 3, jestli jde lepe
sysctl vm.dirty_ratio = 10
sysctl -p

Do SUDOERS uložít výjimku dle Juwa, nastavit skriptu spustitelnost je nutnost a příkaz pro spouštěné po startu/přihlášení bude:

Kód: [Vybrat]

sudo /bin/dirty_bit.sh
Soubor /etc/sysctl.conf možná předtím uvést do původního stavu.

MKeyCZ · « **Odpověď #18 kdy:** 03 Listopadu 2020, 12:24:37 »

Nyní jsem chtěl napsat, ale byl jste rychlejší.

Zkoumal jsem na internetu, co by to, tak mohlo být... V souvislosti s touto diskuzí: https://askubuntu.com/questions/566361/cant-change-vm-dirty-ratio-with-etc-sysctl-conf -> jsem si odůvodnil, že mi "nějaká" aplikace co řídí "energii" notebooku mohla způsobovat potíže..., pak jsem si vzpomněl, že při instalaci ubuntu na svůj notebook jsem postupoval dle článku https://www.tecmint.com/things-to-do-after-installing-ubuntu-20-04/ -> 25 věcí po instalaci ubuntu 20.04.

Kde jsem dle článku nainstaloval: Install Laptop Power Saving Tools -> což byla nejspíše ta chyba.

takže můj postup:
1) odstranil jsem skript, včetně úpravy souboru sysctl.conf
2) odinstaloval jsem výše uvedenou "utilitu":

Kód: [Vybrat]

sudo apt remove laptop-mode-tools && sudo apt autoremove 3) restartoval jsem systém
4) do souboru /etc/sysctl.conf jsem opět přidal tyto příkazy:

Kód: [Vybrat]

vm.dirty_bytes=15728640
vm.dirty_background_ratio = 5
vm.dirty_ratio = 3

5) spustil editaci crontab:

Kód: [Vybrat]

sudo EDITOR=nano crontab -e6)přidal váš příkaz:

Kód: [Vybrat]

@reboot sleep 50 && sudo sysctl -p  ### s menší úpravou času spuštění, aby opravdu žádná aplikace nemohla spuštění přerušit, či zpět vrátit na původní hodnoty.

7) zkontroloval zadaný příkaz:

Kód: [Vybrat]

sudo crontab -l #a crontab -l

-> vše v pořádku

8 ) restart a vypnutí operačního systému
9) kontrola hodnot:

Kód: [Vybrat]

sysctl -a | grep dirty
-> vše se správně načetlo
-> kopírování nyní funguje jak by mělo - zatím to zkouším, ale vypadá to OK

pozn.:
nyní jsem nainstaloval utilitu tlp

Kód: [Vybrat]

sudo apt install tlp-> po restartu i vypnutí OS vše "zatím" funguje.

Ventero · « **Odpověď #19 kdy:** 03 Listopadu 2020, 13:01:28 »

Pokud se něčeho natrvalo zbavujeme, tak pomocí

Kód: [Vybrat]

apt purge

Nejsem si jist, zda si to pamatuji dobře, ale nástroj Install Laptop Power Saving Tools je myslím dobrý jenom na Lenovo - na zbytek je lepší TLP.

Ale schválně - když už jsi v tom - co zkusit i ten postup s tím skriptem? - aspoň by se vědělo víc ..

MKeyCZ · « **Odpověď #20 kdy:** 03 Listopadu 2020, 13:47:26 »

zkusil jsem to, dle vašeho postupu a kopírování opět ukazuje špatně

Ventero · « **Odpověď #21 kdy:** 03 Listopadu 2020, 13:58:58 »

... a bez toho posledniho prikazu v tom skriptu?

Kód: [Vybrat]

sysctl -p.. melo by rlto fungovat uplne stejne jako uprava v tom konfiguraku a jeho nacteni ..
.. tedy za predpokladu, ze ty prime prikazy meni nastaveni sysctl.
Posledni varianta je i s tim poslednim prikazem ci pak jeste bez nej do toho prikazu po spusteni pridat zpozdeni - jako se to dela u Conky.

MKeyCZ · « **Odpověď #22 kdy:** 03 Listopadu 2020, 14:05:07 »

Možná opravdu za to že příkaz funguje může to opoždění 50 sekund po spuštění systému.

juwa2 · « **Odpověď #23 kdy:** 03 Listopadu 2020, 14:06:23 »

Citace: Ventero 03 Listopadu 2020, 13:58:58

... a bez toho posledniho prikazu v tom skriptu?
Kód: [Vybrat]
sysctl -p

Já bych tam naopak nechal jenom sysctl -p a přidal prodlevu

Kód: [Vybrat]

#!/bin/bash
sleep 50
sysctl -p

A pokud chceš příkazem něco zapsat do /etc/sysctl.conf tak se to dělá takto

Kód: [Vybrat]

echo vm.dirty_bytes=15728640 >> /etc/sysctl.conf
případně

Kód: [Vybrat]

bash -c "echo 'vm.dirty_bytes=15728640' >> /etc/sysctl.conf

JirkaZ · « **Odpověď #24 kdy:** 03 Listopadu 2020, 14:06:41 »

Podle mě popisovaný problém souvisí s asynchronním či synchronním způsobem přenosu z PC do USB flash klíčenky.

Vyskytovalo se to už kdysi dávno (tuším v openSUSE?) a tehdy byl defaultní způsob připojení asynchronní. To způsobovalo, že se data rychle uložila do nějaké cache a odtamtud se ukládala do USB flash pouze tak rychle, jak to ona dovolovala. Potíž byla tehdy i v tom, že systém falešně hlásil ukončení přenosu, přičemž přenos ve skutečnosti stále běžel...

Už si nevzpomínám, jak se to konkrétně řešilo, nicméně pomohla změna na synchronní připojení. Přenos se jakoby silně zpomalil, ale to, co ukazoval systém, odpovídalo skutečnosti a nebyla tam ona zdánlivá "zaseknutí" někde před 100%.

Dnes mají USB flash o dost rychlejší zápis (čili zpomalení by nemuselo být podstatné), nicméně vůbec netuším, jak konkrétně se v soudobém *buntu (a i jiných distribucích) připojují obecné USB flash*. Je to téměř vždy nějakým druhem automountu, ale pokud vím, tak s etc/fstab to nijak nesouvisí a jak to skutečně pracuje, to netuším...

Tady https://bbs.archlinux.org/viewtopic.php?id=176752 a v tamních odkazech (třeba https://bbs.archlinux.org/viewtopic.php?id=193089) je cca pět let stará diskuse na toto téma...

(*) Klíčová slova k dalšímu hledání by mohla být něco jako dbus, udisks, udisks2 atd.