Scrollování

Roky mám na čelní pozici mého buylistu trackball. Od roku 2015 ho používám v práci, takže má ruka kroutí kulí minimálně osm hodin denně. I z toho důvodu jsem doma stále věrný myši - aby ruka měla trochu pestřejší škálu pohybů. Nicméně teď mám chuť myš hodit z okna a trackball si pod stromeček pořídit. Proč?

Protože má myš ve Void Linuxu nemožně pomalu scrolluje. Zkoušel jsem už i pracovní trackball, ten potíž nemá. U myši musím otočit kolečkem o 360 stupňů, aby se stránka v čemkoliv grafickém posunula o jeden jediný řádek textu. Jsou situace, kdy je to otravnější než křupající kolenní kloub a i tady vím o čem mluvím. Googlení nepomohlo. Proč? Proč já?

Pěší duševní hygiena

Nejsem morous jen technický, ale s postupujícím věkem zcela všeobecný. A pro morouse je úplně nejhorší neustále se potkávat s lidmi. To máte rodinu - samí lidi, práci - také převážně lidi, vylezete ven z bytu - pes a s ním lidi. Všude lidi. Hrůza!

Proto jsem už dávno začal s takovou malou soukromou očistou od lidí: když už to nejde, sednu do auta, odjedu někam dostatečně daleko od Prahy a tam alespoň půl dne jdu z náhodně vybraného bodu A do náhodně vybraného bodu B tak, abych lidí potkal co nejméně. Obvykle je to spojené s geocachingem, poslechem buď podcastů nebo vysílačky (jen poslech, sám nemluvím); ideální je, když se počet kilometrů takto ušlých blíží dvacítce, ještě lepe, když ji překračuje. Jednoho krásnýho dne mám v plánu ráno vstát, nasnídat se a vyrazit pěšky na Ještěd - zatím ale tak daleko ještě nejsem, dá se říct, že zatím jen trénuju. S výjimkou odlovu Trejlíčku jsem ale dlouho nikde netrénoval, takže jsem se rozhodl, že posledních šedesát kešek z této série počká, já chci někam jinam!

Vždycky, když jsem na mapě viděl Kutnou Horu a Čáslav, říkal jsem si, že musí být moc pěkné, vzít to mezi nimi pěšky. Trať, která je spojuje, se mezi nimi mění ze stejnosměrné na střídavou, potkáte tu tedy jak stodvacettrojky, tak dvěstěčtyřicítky a dvěstětřicítky, radost pohledět. Kousek za kopcem vám do toho startují Grippeny, na radiových pásmech je sem slyšet zdaleka, krajina tu také není ošklivá, jde se na to!

Kromě již běžné GPS, mobilu, sluchátek a vysílačky jsem s sebou tentokráte musel zabalit i služební notebook, co čert nechtěl totiž na den výšlapu připadly dlouho plánované disaster recovery testy SAPu. Se zátěží na zádech to ale nakonec byla větší legrace a jestli mě někdo viděl, jak zablácený do půlky lýtek s oběma botama mokrýma ve větru a pošmournu na lavičce na návsi ťukám do notebooku, doufám, že jsem ho alespoň rozesmál.

Bylo z toho (i s těmi testy a obědem) nakonec moc hezkých šest hodin mimo běžnou realitu, necelých dvacet kilometrů v nohách, dva poslechnuté podcasty, patnáct odlovených kešek a pětadvacet mobilně-uměleckých krajinek. A až k branám Čáslavi jsem potkal jen jednoho jediného člověka. Příště se zas vrátím k lovení Trejlíčku, ale jen co ho budu mít už konečně z krku, začnu tyhle pěší léčebné kúry prodlužovat. Jednou až na Ještěd.

Nic neuspěchat

Věci se nemají zbytečně uspěchat. Tak třeba můj Mac Mini Core Duo. Mám ho čtyři roky, z toho je tři a půl roku pod televizí a slouží jako nepravidelný přehrávač z internetu stažených filmů a seriálů. A celou tu dobu si říkám, že musím nějak vyřešit jeho bezdrátové ovládání. Dálkáč od Apple má play, pause, stop, next, prev a ovládání hlasitosti, tím se možná dobře ovládá DVD přehrávač, ale ne operační systém. Ovládání pomocí VNC zase staré 32-bitové Core Duo nezvládá, pokud nesnížím rozlišení na 480 pixelů na výšku, což ale zase nenese dobře systém. Přemýšlel jsem nad tím dlouho, doslova roky...

A teď mám už řešení. Miniklávesnička z Aliexpressu s integrovaným touchpadem. Podsvícená, napájená dle konfigurace buď 2xAA nebo klasickou nokiáckou mobilní lithiovou baterií. V rámci svatomartinských slev za necelé dvě stovky, z evropského skladu dorazila po deseti dnech od objednávky. Dongle bude trvale umístěn v USB portu, systém s ním neměl žádné potíže a dnešní večer byl Mini používán tak, jako už dlouho ne. Ostatně i tento článek právě dopisuju na něm. Neuspěchal jsem to!

Jednoduché věci jednoduše

Letošní linuxové školení je za mnou a stejně jako vloni i letos jsem si odnesl zajímavé zkušenosti.

Kromě v posledních dnech popisovaného VDO, které ale v praxi zatím na svých domácích počítačích nepoužiju, protože ve Void Linuxu zatím není, jsem si odnesl i spíše filosofický poznatek, že jednoduché věci je lepší dělat jednoduše.

Tak třeba: mám na stole svůj nový starý desktop s Core i3. Na stejném stole zhruba o půl metru více nalevo mám Raspberry Pi 2, které pravidelně zálohuje můj webserver a také je k němu připojen přes USB 750GB disk pro odkládání dat. Doteď jsem se na disk dostával tak, že jsem pomocí Midnight Commanderu dělal SSH spojení a přes něj data kopíroval tam a zpět.

A přitom Linux má přímo v jádře podporu NFS, jak serveru, tak klienta. Konfigurace v /etc/exports na straně serveru a /etc/fstab na straně klienta je tak jednoduchá, že jednodušší už být nemůže. A já to doteď dělal tak pitomě, složitě, skoro powindowsácku. Fuj! Naštěstí už je to opraveno.

V.D.O. (3)

Co se tedy může zvrtnout?

Ideální situace pro VDO je, že máte velké pole, které není ani náhodou plné a vy si ho pomocí VDO ještě zvětšíte. Z deseti terabajtů hardwarových máte dvanáct-třináct terabajtů virtuálních a je to v pohodě, protože na nich leží sotva pět terabajtů dat a uživatelé vám přisypou maximálně několik giga dat nových za den. Slunce svítí, kytičky kvetou, ptáčci zpívají, lepší to už ani být nemůže. Co se tedy může pokazit?

V zásadě jsou to dvě věci:

1. Může dojít místo na virtuálním disku
2. Může dojít místo na fyzickém disku

A co s nimi?

Došlo místo na virtuálním disku

Jinými slovy, komprimovalo a deduplikovalo se více, než jste čekali, df -h hlásí plno, ale pomocí vdostats vidíte, že ještě plno není. Tohle je ta jednodušší situace:

 # df -h .
 Filesystem        Size  Used Avail Use% Mounted on
 /dev/mapper/vdo1   12G  2.6G  8.6G  23% /mnt/looptest
 # cd /
 # umount /mnt/looptest
 # vdo growLogical --name=vdo1 --vdoLogicalSize=13G
 # e2fsck -f /dev/mapper/vdo1
 # resize2fs /dev/mapper/vdo1
 # mount /dev/mapper/vdo1 /mnt/looptest
 # cd /mnt/looptest
 # df -h .
 Filesystem        Size  Used Avail Use% Mounted on
 /dev/mapper/vdo1   13G  2.6G  9.5G  22% /mnt/looptest
 

I když na mém loopback device místo bylo, zvětšit jeho virtuální kapacitu o jeden gigabajt se zjevně povedlo. Pokud by snad na disk byla i nadále ukládána dobře komprimovatelná data, dá se to opakovat dál a dál.

Došlo místo na fyzickém disku

V tomto okamžiku slunce zašlo za mrak, kytičky spálil mráz a ptáčci chcípli. Když se pokusíte uložit něco na disk, jehož filesystém hlásí spoustu volného místa, ale fyzický disk vespod už žádné nemá, nastane peklo. Poslední operace zápisu selže, data se neuloží, vy se to ale na první pohled nedozvíte. Chyby se totiž objeví pouze v dmesg jako I/O error, disk se následně přepne do read-only režimu a končíte:

 # df -h .
 Filesystem        Size  Used Avail Use% Mounted on
 /dev/mapper/vdo1   13G  5.6G  6.5G  47% /mnt/looptest
 
 # vdostats --human-readable
 Device                    Size      Used Available Use% Space saving%
 /dev/mapper/vdo1          8.0G      7.4G      0.6G  93%           37%
 
 # dd if=/dev/urandom of=grand-finale.bin bs=131072 count=8192
 8192+0 records in
 8192+0 records out
 1073741824 bytes (1.1 GB) copied, 5.31326 s, 202 MB/s
 
 # df -h .
 Filesystem        Size  Used Avail Use% Mounted on
 /dev/mapper/vdo1   13G  6.6G  5.5G  55% /mnt/looptest
 
 # vdostats --human-readable
 Device                    Size      Used Available Use% Space saving%
 /dev/mapper/vdo1          8.0G      8.0G      0.0G 100%           34%
 
 # dmesg | tail
 [93859.978067]	EXT4-fs warning (device dm-0): ext4_end_bio:302: 
 		I/O error -28 writing to inode 19 (offset 520093696
 		size 8364032 starting block 1750055)
 [93859.978071]	Buffer I/O error on device dm-0, logical block 1750055
 [93864.336428]	JBD2: Detected IO errors while flushing file data on dm-0-8
 [93864.339959]	Aborting journal on device dm-0-8.
 [93864.340463]	Buffer I/O error on dev dm-0, logical block 1606659,
 		lost sync page write
 [93864.340476]	JBD2: Error -5 detected when updating journal superblock
 		for dm-0-8.
 
 #mount | grep vdo1
 /dev/mapper/vdo1 on /mnt/looptest type ext4 (ro,relatime,data=ordered)
 

Pěkné, což? Ale co s tím?

V reálném světě byste přihodili další disk do RAID pole, na kterém máte data fyzicky uložená, počkali až se rebuildne a pak přes něj roztáhli VDO. V naší malé simulaci pomocí loopback device se to dá vyzkoušet taky. Nejdříve si zvětšíme "fyzické úložiště":

 # umount /mnt/looptest
 # vdo stop --name=vdo1
 # losetup -D
 # dd if=/dev/zero of=fakedisk2.img bs=131072 count=16384
 # cat fakedisk2.img >> fakedisk1.img
 # losetup -fP ./fakedisk1.img
 # lsblk
 NAME           MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
 loop0            7:0    0    10G  0 loop  
 

Disk je tedy větší, teď je třeba modifikovat VDO a následně ho rebuildnout:

 # vdo start --name=vdo1
 # vdo growPhysical --name=vdo1
 # vdostats --human-readable
 Device                    Size      Used Available Use% Space saving%
 /dev/mapper/vdo1         10.0G      8.0G      2.0G  80%           34%
 

A je to. VDO je zase použitelné, filesystém uvnitř žádnou změnu ani nezaznamenal, od počátku viděl kapacitu jinou. Jelikož ale poslední operace nedoběhla správně, je samozřejmě před připojením lepší udělat fsck.ext4. Vzhledem k žurnálovacímu filesystému byste neměli přijít o nic víc, než právě o poslední neúspěšný zápis.

-

Závěrem ještě dvě věci, které nutno specificky zmínit:

• Virtuální zařízení založené na VDO se standardně chová jako SSD i když jde fyzicky o plotnový disk. Tedy při mazání nedochází k uvolňování místa, je zapotřebí pravidelně používat fstrim nebo - pokud používáte filesystém, který to umí sám rovnou - připojovat s parametrem discard.
• Jde o původně proprietární technologii, kterou RedHat pořídil a otevřel světu. Udělal to relativně nedávno, takže jde zatím o doménu hlavně RHEL, CentOS a Fedory. Z distribucí, které zajímají mě (Slackware, Void, Devuan, Gentoo) jsem nějaké zmínky našel akorát u Gentoo, jak jsou na tom mainstreamové, morem a cholerou prolezlé distribuce, nevím.

PS: Asi tyto tři články časem spojím do jednoho a vydám na starém blogu.

V.D.O. (2)

Pojďme si ukázat, jak na to. Podařilo se mi tu dostat o chlup dál, než vyučující zamýšlel - zvládl jsem VDO vytvořit, zaplnit, rozbít, rozšířit a opravit - cílem přitom bylo zůstat pouze u prvního bodu. Nicméně alespoň můžu ukázat vše kompletně od A do Z.

Začněme tedy vytvořením loopback device, na kterém budeme simulovat disk:

 # dd if=/dev/zero of=./fakedisk1.img bs=131072 count=65536
 # losetup -fP ./fakedisk.img
 # lsblk
 

Poslední příkaz vypíše stav blokových zařízení po vytvoření loopbacku, mělo by to vypadat zhruba takto:

 NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
 sda      8:0    0 465.8G  0 disk 
 +-sda1   8:1    0  1000M  0 part /boot
 +-sda2   8:2    0   7.9G  0 part [SWAP]
 +-sda3   8:3    0 456.9G  0 part /
 sr0     11:0    1  1024M  0 rom  
 loop0    7:0    0     8G  0 loop 
 

Nad loopbackem vytvoříme VDO zařízení, kernelu se to nebude líbit, nerad dělá virtuální věci nad virtuálními věcmi, takže ho přinutíme parametrem --force, ten v reálu třeba není.

 # vdo create --name=vdo1 --device=/dev/loop0 --vdoLogicalSize=12G --force
 Creating VDO vdo1
 Starting VDO vdo1
 Starting compression on VDO vdo1
 VDO instance 0 volume is ready at /dev/mapper/vdo1
 

Nad osmigigabajtovým diskem loop0 tedy vytváříme dvanáctigigový virtuální disk vdo1, přičemž to druhé číslo jsme si zcela objektivně vycucali z prstu a doufáme, že to bude v pohodě. Tady je právě to největší úskalí VDO - systém vidí při použití /dev/mapper/vdo1 disk o kapacitě 12 GB, že je založen na fyzickém zařízení o velikosti 8 GB ho vůbec nezajímá. Pokud ukládáte data, která jsou málo duplicitní či špatně komprimovatelná, ke 12 GB se ani nepřiblížíte a nikdo vás neupozorní, že místo došlo. Jen v dmesg se objeví I/O errory a začnou se dít zlé, ošklivé a nepěkné věci. O tom ale dále, teď máme krásný, nový disk o jehož kvalitách se můžeme přesvědčit příkazem vdostats:

 # vdostats --human-readable
 Device                    Size      Used Available Use% Space saving%
 /dev/mapper/vdo1          8.0G      4.0G      4.0G  50%           N/A
 

Toto je jediné místo, kde uvidíte, jak je zaplněno fyzické zařízení. Také zde vidíte, že hned po vytvoření je obsazeno 4 GB místa - to jsou metadata pro fungování VDO, nemá tedy smysl dávat ho na malé disky, chce to alespoň tak velký disk, aby úspora vyrovnala tyto čtyři gigabajty.

Když na novém zařízení vytvoříme filesystém, připojíme ho a koukneme se na jeho parametry, uvidíme jiná čísla:

 # mkfs.ext4 /dev/mapper/vdo1
 # mount /dev/mapper/vdo1 /mnt/looptest/
 # cd /mnt/looptest
 # df -h .
 Filesystem        Size  Used Avail Use% Mounted on
 /dev/mapper/vdo1   12G   41M   12G   1% /mnt/looptest
 

A teď přijde pochopitelně nějaké to testování:

 # dd if=/dev/zero of=nuly.bin bs=131072 count=8192
 # dd if=/dev/urandom of=bordel1.bin bs=131072 count=4096
 # cp bordel1.bin bordel2.bin
 # cp bordel1.bin bordel3.bin
 

Vytvořili jsme čtyři soubory: gigabajtový soubor plný nul, půlgigabajtový soubor plný pseudonáhodného bordelu a dvě jeho kopie. Jak vypadá obsazení disku?

 # ls -lh
 total 2.6G
 -rw-r--r-- 1 root root 512M Nov 19 11:15 bordel1.bin
 -rw-r--r-- 1 root root 512M Nov 19 11:15 bordel2.bin
 -rw-r--r-- 1 root root 512M Nov 19 11:15 bordel3.bin
 -rw-r--r-- 1 root root 1.0G Nov 19 11:14 nuly.bin
 
 # df -h .
 Filesystem        Size  Used Avail Use% Mounted on
 /dev/mapper/vdo1   12G  2.6G  8.6G  23% /mnt/looptest
 
 # vdostats --human-readable
 Device                    Size      Used Available Use% Space saving%
 /dev/mapper/vdo1          8.0G      4.5G      3.5G  56%           80%
 

Vše je asi dle očekávání pozorného čtenáře: filesystém eviduje přes dva a půl gigabajtu dat, VDO ale gigabajt nul uložilo jen jako informaci o tom, že takový soubor existuje, skutečné místo zabírá pouze první půlgigový soubor s bordelem a jeho dvě kopie existují opět pouze v metadatech.

Takhle to tedy vypadá ideálně. Méně příjemné aspekty VDO příště.

V.D.O. (1)

Vzhledem k tomu o jaké věci se zajímám a s jakýma lidma se stýkám, nemůže se nikdo divit, že neznám každou existující technologii s velmi ostrou hranou. Alespoň tak každoroční linuxová školení, z mně neznámého důvodu mi pravidelně placená zaměstnavatelem, mají nějaký přínos. Letos si už z prvního dne odnáším poznání, že existuje VDO.

VDO, neboli Virtual Data Optimizer, je kernelový modul, který umožňuje lepší využití blokových zařízení. Používá k tomu tři principy ve třech po sobě jdoucích fázích:

1. Eliminace zero-bloků - hned v první fázi jsou k dalšímu zpracování poslána jen skutečná data, bloky nul jsou uloženy jako metadata a nic nezabírají.
2. Deduplikace - data bez nulových bloků jsou následně deduplikována, tj. zjišťuje se, zda už někde na disku stejná data jsou. Pokud ano, záznam o dalším jejich výskytu se opět vloží jen do metadat a další místo není zabráno.
3. Komprese - to, co prošlo až do poslední fáze je opravdu zapotřebí někam na disk zapsat a než se tak stane, je to ještě zapakováno pomocí LZ4.

Vypadá to skvěle a kdyby to aktuálně podporovala distribuce, kterou jsem si nainstaloval na svůj nový starý desktop, už bych si VDO na své minipolíčko poštval. Jsou tu ale i jistá úskalí, vše se totiž děje na úrovni blokového zařízení, tedy ještě pod filesystémem, hned příště na příkladu nad loopback device ukážu jaká.