Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Témata - Tomaskom

Stran: [1]
1
Software / Rsync s --append-verify
« kdy: 19. 01. 2018, 15:11:40 »
Zvykl jsem si u rsync v remote zálohovacích skriptech používat parametr --append-verify, jednak pro navázání po případnym přerušení spojení, ale taky aby v takových případech nezůstaly v destinaci ležet skryty nedokončeny fragmenty.

Jenže teď sem si všiml, že se v určité situaci nechová, jak bych čekal.
Pokud se nějaký soubor nepřenesl úplně, v pořádku, naváže se.
Pokud se nějaký soubor změnil a zvětšil se, celkem v pořádku, rsync provede kontrolu obsahu, všimně si změny a přenese ho znova (akorát při tom huláká varování, i když to měl čekat, když má zdroj novější timestamp).
ALE: Pokud se soubor změní, s tím že se jeho velikost nezmění nebo se zmenší, tak ho rsync nepřenese :o (přestože má novější timestamp)
Když odstraním parametr --append-verify, tak vše probíhá normálně a změna se nasynchronizuje.

Nejradši bych, aby rsync zároveň navazoval (s kontrolou dosavadního obsahu), ale taky zároveň nerezignoval na kontrolu timestampu, což teď zjevně dělá. Zatím asi jako workaround ho po dokončení s --append-verify zavolám znova bez něj...

Používám rsync 3.1.0

Vypadá to teda, že ten parametr se má používat jenom po přerušenym spojení, a ne běžně, protože pak ignoruje timestampy. Ale i tak je to problém, pokud při přerušenym přenosu nedošla řada na nějaky další soubory a cíl nebyl prázdnej, tak už je s tím appendem bude posuzovat jinak (IMO špatně).
Je to očekávané chování, nebo bug? (Kdyžtak nareportuju). Osobně bych předpokládal, že i s --append-verify, pokud si všimne že má zdroj novější timestamp, tak normálně změněný soubor přenese. Obyčejnej --append se chová podobně, akorát samozřejmě selže i v případě zvětšení - na novější timestamp na zdroji ale kašle úplně stejně.

Demonstrace:
Kód: [Vybrat]
Tom@HP-ProBook-TK~/temp/rsync_append> mkdir src && mkdir dest && echo aaa > src/a.txt
Tom@HP-ProBook-TK~/temp/rsync_append> rsync -a -v -h --append-verify src/ dest/
sending incremental file list
a.txt

sent 122 bytes  received 35 bytes  314.00 bytes/sec
total size is 4  speedup is 0.03
Tom@HP-ProBook-TK~/temp/rsync_append> cat src/a.txt dest/a.txt
aaa
aaa
Tom@HP-ProBook-TK~/temp/rsync_append> echo aba > src/a.txt
Tom@HP-ProBook-TK~/temp/rsync_append> rsync -a -v -h --append-verify src/ dest/
sending incremental file list

sent 74 bytes  received 12 bytes  172.00 bytes/sec
total size is 4  speedup is 0.05
Tom@HP-ProBook-TK~/temp/rsync_append> cat src/a.txt dest/a.txt
aba
aaa
Tom@HP-ProBook-TK~/temp/rsync_append> rsync -a -v -h src/ dest/
sending incremental file list
a.txt

sent 125 bytes  received 35 bytes  320.00 bytes/sec
total size is 4  speedup is 0.03
Tom@HP-ProBook-TK~/temp/rsync_append> cat src/a.txt dest/a.txt
aba
aba
Tom@HP-ProBook-TK~/temp/rsync_append> echo abaa > src/a.txt
Tom@HP-ProBook-TK~/temp/rsync_append> rsync -a -v -h --append-verify src/ dest/
sending incremental file list
a.txt
WARNING: a.txt failed verification -- update retained (will try again).
a.txt

sent 177 bytes  received 156 bytes  666.00 bytes/sec
total size is 5  speedup is 0.02
Tom@HP-ProBook-TK~/temp/rsync_append> cat src/a.txt dest/a.txt
abaa
abaa

2
Software / Návrat plánovače BFQ
« kdy: 12. 02. 2016, 20:38:39 »
U konkurence sem zahlidl clanek: http://www.abclinuxu.cz/clanky/jaderne-noviny-4.-2.-2016-navrat-planovace-bfq
Jak to mate vy s I/O schedulery?
Osobne na desktopovym systemu (notebook s rotacnim diskem) uz delsi dobu pouzivam deadline, protoze CFQ silne zaostava napr. pri prehravani hudby, pokud na pozadi bezi intenzivni cteni (rsync zaloha na externi disk, ktery je rychlejsi nez interni v notebooku). Prehravac (Clementine) obcas vyhladovi a prestane hrat, i kdyz mam buffer na 8s. S deadlinem sem mnohem spokojenejsi, i kdyz jeho celkovy vykon pri narazu na deadline cteni je znatelne nizsi. Odstrani ale ty extremni problemy. S nastavovanim I/O priorit se me nechtelo babrat.

Rad proto vidim, ze ma urcitou sanci na zarazeni do jadra novy planovac, ktery podle dosavadnich benchmarku vypada hodne slibne (https://lwn.net/Articles/674300/ tabulka ke konci). At uz CFQ (ze ktereho puvodne vychazi) nahradi, nebo pribude jako nova moznost.

3
O serveru Root.cz / Zvýraznění odkazů v boxu fór
« kdy: 16. 09. 2013, 13:51:40 »
Dlohodobě sem zvyklý sledovat nové příspěvky v zajímavých vláknech na fóru přes výpis nejnovějších příspěvků na hlavní stránce root.cz. Fungovalo to velice jednoduše, jednou za čas sem na to koukl a projel vlákna, kde se řešilo něco zajímavého a byly tam nové příspěvky. Jestli byly od posledního prohlížení nové jsem poznal jednoduše - pomocí zvýraznění navštívených odkazů.
Poslední dobou to ale už nefunguje, na vině je očividně část v odkazu
Kód: [Vybrat]
...&icc=item-1která udává pořadní v onom výpisu. Takže změna jiných vláken způsobí změnu pořadí a tím i tohoto čísla a zmiznutí zvýraznění, i když se v daném vlákně nic nového nedělo.

Je to nějakým způsobem potřebný údaj, nebo by se bez tohoto označení zdroje vstupu do vlákna fórum obešlo? Nestačí vědět, že člověk přišel přes odkaz z onoho výpisu novývh příspěvků, bez konkrétního pořadí?

4
O serveru Root.cz / Další díl seriálu o kvadrokoptéře?
« kdy: 02. 05. 2013, 00:18:04 »
Je to už skoro měsíc od posledního článku, hodlá autor pokračovat? Nebo jen řeší komplikace, případně prostě nemá čas? Zrovna tento projekt mi přišel velice zjímavý...

Stran: [1]