19. listopadu 2019
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ě.