Btrfs - jak uvolnit místo

22.12.2020 20:18 | Přečteno: 2288× | Za vším hledej Linux |

Zdědil jsem virtuální server na němž je mimo webu také sdílené úložiště přístupné přes WebDAV. Jeho virtuální disk měl pouhých 40GB, což není moc, takže jsem chtěl předejít situaci, že by někdo svými daty vyčerpal veškerou diskovou kapacitu a tak, byť neúmyslně, způsobil jeho kolaps. Mít ho na Btrfs, tak by to nebyl problém. Vytvořil bych subvolume a nastavil kvóty. Jenže tenhle server měl pouze jeden diskový oddíl formátovaný na ext4, takže jsem nemohl využívat ani výhod snapshotování. Šel jsem na to tedy jinak.

Rozhodl jsem se rovnou oběhovat část kapacity virtuálního disku tím, že jsem na něm vytvořil soubor o velikosti 16GB, který jsem následně připojil přes looback a zformátoval na Btrfs. A takhle už to běží asi 6 let. Záznam v souboru /etc/fstab vypadá takto:

~# cat /etc/fstab 
UUID=01ec1b7f-5a05-42a4-8032-130693a4c959 /               ext4    errors=remount-ro 0       1
/home/user/dav.img /home/user/dav btrfs loop,subvol=webdav 0 0
…

Mezi tím se ukázalo se, že zvolená kapacita sdíleného úložiště je zbytečně velká. Zato původní web se poněkud rozrostl. Proto jsem se odhodlal k tomu, abych onen virtuální disk zredukoval na polovinu. Ovšem nejdřív bylo nutné uvolnit zabrané místo. O tom, jak vypadala výchozí situace se můžete přesvědčit zde:

~# mount
…
/dev/vda1 on / type ext4 (rw,relatime,errors=remount-ro)
…
/home/user/dav.img on /home/user/dav type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/webdav)
…
~# df -h
Souborový systém Velikost Užito Volno Uži% Připojeno do
…
/dev/vda1             39G   32G  5,3G  86% /
…
/dev/loop0            15G  2,9G  9,7G  23% /home/user/dav
…

Teď asi možná někdo kroutí hlavou co na tom řeším, když z 15G je obsazeno pouhých 23% tedy 2,9G. Jenže když se podíváte pořádně na následující výpis, tak si můžete všimnout, že je ve skutečnosti zabráno 7G a ne jenom 2,9.

~# btrfs fi show /home/user/dav
Label: 'DAV'  uuid: 181c497e-28c0-4547-b1e6-ca13f355a2de
        Total devices 1 FS bytes used 2.81GiB
        devid    1 size 15.00GiB used 9.58GiB path /dev/loop0

~# btrfs fi df /home/user/dav
Data, single: total=7.01GiB, used=2.81GiB
System, DUP: total=32.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, DUP: total=1.25GiB, used=7.61MiB
Metadata, single: total=8.00MiB, used=0.00B
GlobalReserve, single: total=16.00MiB, used=0.00B

Fajn. Btrfs na to ale má řešení.

~# btrfs balance start /home/user/dav
WARNING:

        Full balance without filters requested. This operation is very
        intense and takes potentially very long. It is recommended to
        use the balance filters to narrow down the scope of balance.
        Use 'btrfs balance start --full-balance' option to skip this
        warning. The operation will start in 10 seconds.
        Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting balance without any filters.
Done, had to relocate 13 out of 13 chunks

~# btrfs fi df /home/user/dav
Data, single: total=3.00GiB, used=2.80GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=256.00MiB, used=7.20MiB
GlobalReserve, single: total=16.00MiB, used=0.00B
~# btrfs fi resize -8g /home/user/dav
Resize '/home/user/dav' of '-8g'
~# df -h
Souborový systém Velikost Užito Volno Uži% Připojeno do
…
/dev/vda1             39G   32G  5,3G  86% /
…
/dev/loop0           7,0G  2,9G  3,7G  44% /home/user/dav
…
/home/user/dav.img

Rebalancování onoho virtuálního disku zabralo cca minutu, protože jsem měl zabráno fakt prd. Kdybych měl dat více a měl k dispozici více RAM, tak by se to dalo urychlit s využitím ramdisku. Takto:

Jak jste se mohli sami přesvědčit, objem zabraných dat na loop zařízení klesl na pouhé 3G, takže jsem s klidem mohl udělat shrink o celých 8G a velikost souborového systému na loop zařízení se zmenšila na 7G. Jenže…

~# ls -alh /home/user/dav.img
-rw-r--r-- 1 root root 15G pro 22 16:48 /home/user/dav.img

Jak vidíte, velikost virtuálního disku zůstala beze změny. Takže bylo nutné udělat ještě jednu operaci – “smrsknout“ virtuální disk. K tomu ovšem bylo nutné na chvíli odstavi apache, aby na něj nehrabal, a ještě před odmoutováním zjistit kolik místa zabírá ten souborový systém v K. Terve pak bylo možné použít truncate, virtuální disk opět namountovat a opět nahodit apache:

~# systemctl stop apache2 && sync
~# df
Souborový systém 1K bloků    Užito   Volné Uži% Připojeno do
…
/dev/loop0        7340032  2972932 3807420  44% /home/user/dav
…
~# umount /home/user/dav && sync
~# truncate -s 7340032K /home/user/dav.img 
~# ls -al /home/user/dav.img
-rw-r--r-- 1 root root 7,0G pro 22 18:56 /home/user/dav.img
~# mount /home/user/dav
~# systemctl start apache2

       

Komentáře

[Vantomas]

Když už se vypínal Apache, tak by mi snad přišlo jednodušší celý disk převést na btrfs.

[Aleš Kapica]

Riskantní.

[Vantomas]

Proč by to bylo riskantní? Je tam nějaká složitá změť oprávnění a ACL?

Já jsem se zatím nespálil a již jsem několik virtuálu na btrfs bezproblému převedl. Dělám to tak, že do virtuálu přidám další disk, na něj mkfs.btrfs, přes rsync přenést data z běžícího systému, upravit fstab, naladit grub, povypínat všechny služby a procesy, znovu udělat rsync s --delete, virtuál vypnout, vyhodit disk s ext4 a spustit z nového.

[Peter Golis]

Nebolo bezpečnejšie zavolať FSTRIM aby sa to miesto uvoľnilo?

[Aleš Kapica]

Co se ti nezdá na balance?

[pavele]

Nebylo by jednodušší vytvořit virtuální disk jen na data?

Ten se může zaplnit třeba až na maximum.

Mám virtuální OS na jednom virtuálním disku a data na dalším virtuálním disku.

Výhoda je v zálohování OS (velikost disku).

Ale jinak je to pěkné, možnost snapshotů se hodí.

[Aleš Kapica]

To těžko, když nemám přístup k virtualizačnímu prostředí. Kdybych si mohl jednoduše přidat disk, tak bych vůbec tuhle opičárnu neřešil.

[Heron]

Uff, to se mi ulevilo.

To nešlo tuhle prasárnu odmítnout?

[Peter Golis]

To uvolnenie miesta sa stalo pro ballance na BTRFS alebo až po truncate na daný súbor?

Len toľko. Ale inak je tá prvá časť o BTRFS rozpísaná pekne, tú nespochybňujem. Tá sa mi páčila.

[Aleš Kapica]

Až po truncate. A to jsem nezmínil, že se mi mezitím podařilo ten disk zaplácnout, když jsem ho chtěl zatarovat do komprimované zálohy. Naštěstí jsem si toho všimnul poměrně včas. Takže jsem to vyřešil jinak. Soubor dav.img jsem pro jistotu odsypal přes scp, a pak smrsknul.

[MadCatX]

Pokud tam zabíraly místo servisní chunky btrfs, fstrim to nevyřeší. Už jsem na to taky narazil při kopírování velkého množství souborů z jednoho disku na druhý.

[Peter Golis]

Ja som ale reagoval na ten truncate, no nevadí.

[Aleš Kapica]

Nevím. Nenapadlo mě to, nevyzkoušel jsem. Každopádně apriori zmenšení souborového systému neznamená "smrsknutí" blokového zařízení jako takového, pokud vím. Takže jsem raději zvolil osvědčenou cestu přes truncate.

Mimochodem, většina lidí nechápe, že u zaplněného COW systému, jako je Btrfs, nelze uvolnit místo tím, že se smaže nějaký soubor. Nepůjde to. A řešením je právě truncate. Protože po smrsknutí na nulovou velikost už to půjde.

[Peter Golis]

Ono je garantované že to BTRFS ballance presunie všetky dáta na začiatok disku? To som nevedel, a radšej by som sa na to nespoliehal.

Samotný FSTRIM vystrieľa diery aj cez loopback tak, aby vznikol sparse file a uvoľnilo sa nepoužívané miesto. Nevravím že to funguje na 100%, ale pripadá mi to bezpečnejšie. I keď, práca na low level úrovni je vždy riziková, a mala by jej predchádzať záloha cenných údajov.

[Heron]

Ono je garantované že to BTRFS ballance presunie všetky dáta na začiatok disku?

No, proto je tam ten resize.

btrfs fi resize -8g /home/user/dav

[Peter Golis]

Tak ten som si nevšimol, priznám sa.

Pozrel som si to ako nápad, vytvoril sparse loopback, nahodil BTRFS, plnil mu FS náhodnými dátami (z ktorých som trochu odmazával aby nastávala fragmentácia) a potom som jednoducho pustil FSTRIM. Výsledok, teda zmenšenie nosného súboru som mal hotový v jednom kroku ktorý sa ajtak spúšťa automaticky raz za týždeň. Ale toľko sa mi nechcelo čakať.

[Heron]

Tak ten som si nevšimol, priznám sa.

Já napoprvé také ne a vrtalo mi to hlavou. A zjistil jsem, že btrfs check je úplně jedno, že se mu zmenšil blockdevice.

lvcreate -L 64G -n btrfs VGData

btrfs fi show
...
devid    1 size 64.00GiB used 20.00MiB path /dev/mapper/VGData-btrfs

Zmenšíme to:

lvreduce -L 16G /dev/VGData/btrfs

btrfs fi show
...
devid    1 size 64.00GiB used 20.00MiB path /dev/mapper/VGData-btrfs

A check ani nepípne:

btrfs check /dev/VGData/btrfs 
Opening filesystem to check...
Checking filesystem on /dev/VGData/btrfs
UUID: a1f63e1d-33d0-4759-bb81-987c2b37f099
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 655360 bytes used, no error found
total csum bytes: 0
total tree bytes: 131072
total fs tree bytes: 32768
total extent tree bytes: 16384
btree space waste bytes: 124530
file data blocks allocated: 524288
 referenced 524288

Oni asi věděli, proč ho nepsali. Ještě by někdo chtěl, aby fungoval.

Ano, zkoušel jsem to na prázdném FS. K otázce, jestli balance strká bloky dopředu, no zdá se že ano (podle chování při balance a následném shrinku), ale asi to není nikde deklarovaná vlastnost.

Pozrel som si to ako nápad, vytvoril sparse loopback, nahodil BTRFS, plnil mu FS náhodnými dátami (z ktorých som trochu odmazával aby nastávala fragmentácia) a potom som jednoducho pustil FSTRIM.

Jo, toto funguje, pokud se výchozí "blockdevice" vytvoří jako sparse. Což asi ne každý dělá nebo chce. Umějí to i widle na iscsi, svého času jsem takto měl ntfs disky ve widlích přes iscsi, protože se mi nechtělo mít v herním kompu rotační disky a ssd byly malý.

[Peter Golis]

toto funguje, pokud se výchozí "blockdevice" vytvoří jako sparse.

Čudné na tom je to, že som si nevytvoril sparse file, a fungovalo mi to.

[Heron]

Aha, tak že by loop uměl prostřílet díry i v normálním souboru? Jako jde to, ale (asi) by měl respektovat původní nastavení.

[Peter Golis]

Keby loopback device filtrovalo akékoľvek nízkoúrovňové príkazy, tak by zapríčinilo zaujímavú (ne)funkcionalitu.

[Heron]

Fak že jo.

# dd if=/dev/zero of=bigfile bs=1M count=16384

# du bigfile
16777216	bigfile

# losetup --find --show bigfile 
/dev/loop0

Zajímavé je, že BTRFS detekuje SSD. A teď proč? Buď mu schopnost discard posílá přímo LOOP, nebo LOOP ví, že je na SSD a tuto vlastnost propouští. Bohužel nemám k disposici HDD, na kterém bych to teď rychle vyzkoušel:

# mkfs.btrfs /dev/loop0
btrfs-progs v5.9 
See http://btrfs.wiki.kernel.org for more information.

Detected a SSD, turning off metadata duplication.  Mkfs with -m dup if you want to force metadata duplication.
Label:              (null)
UUID:               ecb9cfc8-1269-45d8-ba11-4f745233f3ed
Node size:          16384
Sector size:        4096
Filesystem size:    16.00GiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         single            8.00MiB
  System:           single            4.00MiB
SSD detected:       yes
Incompat features:  extref, skinny-metadata
Runtime features:   
Checksum:           crc32c
Number of devices:  1
Devices:
   ID        SIZE  PATH
    1    16.00GiB  /dev/loop0

# mount /dev/loop0 /mnt/btrfs

Protrimujem to:

# fstrim /mnt/btrfs 

# ls -l
total 262960
-rw-r--r-- 1 root root 17179869184 Dec 23 18:38 bigfile

# du *
262960	bigfile

Jo, takže to prostřílel, i když to na začátku nebyl sparse file. Jestli budu mít čas a vzpomenu si na to, tak to ještě zkusím na HDD.

Podkladový FS XFS. Debian Testing, 5.9.0-4-amd64

[Peter Golis]

Ono to fungovalo aj na rotačných HDD už pred cca piatimi rokmi.

Ku vtedajšej spoľahlivosti sa nevyjadrujem, mal som s tým pred piatimi rokmi jeden problém (obraz disku z PPC Mac Mini, a na ňom apple partícia vytvorená pochopiteľne na Big Endian, trim takéhoto niečoho mi na Little Endian stroji slušne povedané zblbol daný obraz disku v súbore). Mal som to zaarchivované, takže žiadna škoda nevznikla. Len som nechcel mať tak veľkú pracovnú kópiu.

Ale za 5 rokov sa toho v IT svete zmení veľmi veľa, a možno opravili strieľanie dier aj s rozdielnou endianitou.

[Heron]

Ok, v tom případě moc nerozumím tvému komentáři. V tomto případě loop nic nefiltruje, ale naopak pokytuje vlastnosti, které na podkladovém zařízení nejsou. A je zcela normální, že block device (v tomto případě dokonce regular file) spoustu věcí nepodporuje (třeba discard u hdd) a ten loop jej vesele reporuje tomu vnitřnímu FS.

O důvod víc to nepoužívat jinak než pro RO vytažení dat z image zachránených disků.

[Peter Golis]

Loop device vytvára blokové zariadenie zo súboru. Súbor umožňuje vystreliť prázdne miesto (punch hole) o ktoré sa zmenší obsadená veľkosť daného súboru. Tak to funguje roky rokúce.

Nerozumiem prečo by mal túto vlastnosť povoľovať alebo zakazovať podľa toho či je ten disk na SSH alebo HDD. Punch Hole nie je Wear Leveling.

[Heron]

Súbor umožňuje vystreliť prázdne miesto (punch hole) o ktoré sa zmenší obsadená veľkosť daného súboru.

To je jasné, ale to ještě neznamená, že loop musí tuto vlastnost automaticky použít. Tj aktivně tomu FS reportovat, že blockdevice loop0 umí discard. To není automatická vlastnost všech blockdevice a před pár lety to byla spíše výjímka. A ano, do souboru se umí dělat díry, ale ne každý admin to automaticky chce.

Nenašel jsem možnost ten loop nějak nastavit (krom size, offest, apod), třeba to nějak jde.

Nerozumiem prečo by mal túto vlastnosť povoľovať alebo zakazovať podľa toho či je ten disk na SSH alebo HDD.

To byla jen úvaha, že by tuto vlastnost dědil z FS na kterém je ten zdrojový soubor. Tj aby FS v loopu měl stejné podmínky, jako FS na kterém leží zdrojový soubor.

[Peter Golis]

Tá tvoja úvaha má jednu slabosť: Punch Hole nie je Wear Leveling. Že sa oboje dá urobiť pomocou TRIM je vedľajšie.

[Heron]

Proč furt mluvíš o wear leveling? Já to nikde nezmiňuju!

Jinak jo, umí to i FALLOC_FL_ZERO_RANGE. Tj podle toho, co si vrstva nad tím zavolá.

[Peter Golis]

Preto že tvoja úvaha že by sa mal loopback chovať pri príkaze TRIM podľa toho či je na SSD alebo HDD je scestná. TRIM na SSD zoberie nepoužívaný blok, a povie SSD že ho môže znovu použiť, tým sa zaradí do poradovníka pre Wear Leveling. Trim na HDD nevykoná nič. Ale Trim na LoopBack vystrieľa sám do seba diery na miestach ktoré už nepoužíva, a zmenší sa tak. SSD sa nezmenšuje, a podobne.

[Heron]

Preto že tvoja úvaha že by sa mal loopback chovať pri príkaze TRIM podľa toho či je na SSD alebo HDD je scestná.

Ne, není. Blockdevice běžně dědí (nebo může) vlastnosti z nadraženého blockdevice nebo poskytují další data (třeba velikosti a rozložení stripu). Tj tato moje myšlenka vedla právě k tomu dědění. Nic víc! O žádném wear levelingu apod jsem nikdy nemluvil! Aneb jak jedna malá věta dokáže někoho vést na zcestí.

Jinak, pokud tuhle zbytečnost teda ukončíme a vrátíme se k věci, tak ono je to teda ještě horší, než jsem si myslel:

Pokud chce vyšší vrstva (tedy FS v loop device) DISCARD, dostane automaticky PUNCH_HOLE (bez možnosti konfigurace):

case REQ_OP_DISCARD:
	return lo_fallocate(lo, rq, pos, FALLOC_FL_PUNCH_HOLE);

Jenže, pokud to chce jen vynulovat, tak dostane by default taky PUNCH_HOLE, pokud si neřekne jinak (a zatím jsem nenašel možnost to nastavit).

case REQ_OP_WRITE_ZEROES:
	/*
	 * If the caller doesn't want deallocation, call zeroout to
	 * write zeroes the range.  Otherwise, punch them out.
	 */
	return lo_fallocate(lo, rq, pos,
		(rq->cmd_flags & REQ_NOUNMAP) ?
			FALLOC_FL_ZERO_RANGE :
			FALLOC_FL_PUNCH_HOLE);

A to je to, o čem jsem mluvil, že to automaticky dělá díry do souborů i když admin nechce. Tj do toho FS to reportuje vlastnost discard (tj fs to detekuje jako SSD, viz výpis mkfs.btrfs), a na základě toho, že mu tam FS posílá discard, dělá díry do souboru (což nejde vypnout; tj že by admin třeba nastavit to vynulování - discard vždy dělá díry). U toho zeroout by to nějak snad mohlo jít vypnout, ty vynutit si zákaz disard v tom fs v loopu a potom ten loop nějak přesvědčít, aby nedělal díry, ale zkutečně tam zapsal ty nuly.

[Peter Golis]

Stále nechápem čo ťa vedie k úvahe že to smie fungovať len na SSD a na HDD to nesmie fungovať. Ale kľudne založ ticket na kernel.org že to majú zle.

[Heron]

nechápem

Ano a po x té už to prostě psát nebudu. Upnul ses na nesmysl, který jsem nikdy nenapsal.

[Peter Golis]

Súhlasím že je to nezmysel. A zaujíma ma prečo by, ako stále tvrdíš, mal loopback device upravovať svoje chovanie pre TRIM podľa toho či je jeho back file na SSD alebo na HDD. Hlavne ak loopback ten TRIM nepreposiela ďalej, ale interpretuje ho podľa svojích potrieb.

[Heron]

ako stále tvrdíš

Kde to stále tvrdím? Nikde jsem to netvrdil, 5x jsem to vyvrátil. Tohle je nějaká vánoční společenská hra? Tak ještě tak dvě kola, ok? Potom jdu dělat něco užitečnějšího

[Peter Golis]

Ono sa to točí okolo tvojho rešpektovania pôvodného nastavenia:

Aha, tak že by loop uměl prostřílet díry i v normálním souboru? Jako jde to, ale (asi) by měl respektovat původní nastavení.

Takže naozaj by mal loop device pri TRIM rešpektovať či je na SSD (a vystrieľať diery) alebo či je na HDD (a nič nerobiť) aj keď hole punching nemá nič s podkladovou vrstvou SSD/HDD? Nuž to znie veľmi zaujímavo, a rád by som vedel ako by sa mal loop device zachovať napríklad na stále bežných hybridných diskoch, DVD RAM vynecháme ako módny výstrelok ktorý sa neuchytil.

Kľudne pokračuj, rád sa dozviem niečo o strategickom plánovaní funkcionality ovládačov blokovej vrstvy.

[Heron]

Ono sa to točí okolo tvojho rešpektovania pôvodného nastavenia

Aha, tak že by loop uměl prostřílet díry i v normálním souboru? Jako jde to, ale (asi) by měl respektovat původní nastavení.

Kde není o SSD ani slovo.

Je to reakce na tvůj komentář:

Čudné na tom je to, že som si nevytvoril sparse file, a fungovalo mi to.

A i komentář před tím se točí okolo sparse vs normální soubor. Tj o SSD (z mé strany) nepadlo ani slovo a diskuse se vedla kolem toho, zda loop respektuje klasický soubor. Další (moje) bádání přineslo informaci, že nerespektuje a naopak preferuje vytváření sparse file pomocí punch hole. Ani slovo o SSD.

[Peter Golis]

Už tomu rozumiem. Takže by to podľa teba malo len skontrolovať či bol podkladový súbor vytvorený ako Sparse, a rešpektovať to. A ak nebol ten súbor vytvorený ako sparse, tak by loopback doň nemal vystreľať diery. Tým pádom si počkám na bugreport. Ideš to predsa vyreportovať keďže si to už úspešne vyskúšal na SSD:

Jo, takže to prostřílel, i když to na začátku nebyl sparse file.

[trekker.dk]

A to je to, o čem jsem mluvil, že to automaticky dělá díry do souborů i když admin nechce.

Akorát je otázka, jestli admin skutečně nechce, tj. jestli v reálném (nikoliv teoretickém) nasazení existuje důvod, proč ty díry nechtít dělat. Vzhledem k tomu, že za ty roky nikomu nestálo za to věnovat čas tomu, aby to šlo (např. bylo přepínatelné pomocí nějakého flagu při vytvoření toho loop device), tak to asi není tak kritické.

[Peter Golis]

Ja osobne tiež nevidím ani najmenší dôvod prečo by loopback nemal interpretovať TRIM na hole punching, teda na scvrknutie virtuálneho disku. Funguje to jak na SSD, tak aj na rotačnom HDD.

A stále mám dojem že to dedenie vlastností z podkladového zariadenia je blbosť. Jednak sa TRIM vykonáva na SSD inak ako na loopbacku, a druhaq by bolo potom zaujímavé vedieť ako sa to má chovať pri hybridných diskoch alebo hybridnýých diskových poliach. A tretiaq, losetup má na prestavenie takého chovania parameter --direct-io, ktorý ale zas nie je určený na hole punching.

[Heron]

důvod, proč ty díry nechtít dělat

Tak důvodů může být víc. Sparse soubor je ze své přirozenosti mnohem fragmentovanější a tedy mnohem pomalejší (na sekvenční zápis / čtení). Tohle je třeba i vlastnost ZFS ZVOL, kdy se vždy vytváří jako sparse a nelze jej předalokovat, ale výkon teda odpovídá tomuto typu. Tj sekvenční rychlost zvolu je o dost nižší, než při použití skutečného souvislého blokového zařízení (tj třeba LV). Dneska na SSD / NVMe je už to skoro jedno, ale na HDD je rozdíl velký (200MB/s vs 60MB/s a to ještě na poměrně mladém čistém zfs). Proto třeba pro disky VM preferuju LVM, čisté lineární blokové zařízení s plnou rychlostí disku.

Potom management místa na disku. Pokud nahraju a připojím (rw) 500GB souboru s image nějakého FS a přes noc se stane naplánovaný fstrim -a a smrskne se to na 30GB, tak náhle mám víc volného místa na disku (než bych "měl" mít). Což může být problém při zaplnění disku a následného zápisu do toho připojeného FS. Tedy je to starost navíc. (zfs ve výchozím stavu rezervuje místo na disku pro zvol, lze to vypnout - tj pokud bych ten 500GB image nahrál do zvolu, tak sice bude zabírat jen 30GB, ale těch 500GB bude stále rezerováno - tohle na klasickém FS, kde je loop soubor prostě jen soubor, by default nemám, musel bych dělat quoty apod.)

Další věc, která ale přímo nesouvisí s vytvářením děr do toho souboru je to, že loop se (automaticky? - /sys/block/DEV/queue/rotational) tváří jako ssd, resp FS jej tak interpretují (tj podporuje discard). To může u některých FS změnit způsob chování k tomu zařízení (viz třeba option ssd / nossd v mountu btrfs). Dopad na výkon toho FS by se musel změřit.

Vzhledem k tomu, že za ty roky nikomu nestálo za to věnovat čas tomu

Tak ona je spíš otázka, jestli se někde reálně masivně nasazuje loop pro zápis v produkčním prostředí. Loop se používá pro mount různých squashfs nebalíčků (snap), ale tj ro.

[trekker.dk]

Vzhledem k tomu, že za ty roky nikomu nestálo za to věnovat čas tomu

Tak ona je spíš otázka, jestli se někde reálně masivně nasazuje loop pro zápis v produkčním prostředí.

Jo, to bude jedno souviset s druhým. Když pominu různé "potřebuju se podívat do ISO souboru", nenapadá mě žádný dobrý důvod, proč v produkci používat loop místo jiného (s největší pravděpodobností rozumnějšího a čistšího) řešení.

[Tom K]

Uvedené důvody pro nepoužívání TRIMu jsou dobré. Proto má každý slušný souborový systém možnost TRIM používat nebo nepoužívat (předpokládám, že BTRFS taky). Stav, kdy se u LOOP device TRIM chová jinak než u fyzického disku může být trochu matoucí, ale přiznejme si, že LOOP je sám o sobě speciální případ, takže bych mu to nevyčítal. Naplánovaný fstrim a podobné drobnosti jen ukazují, že přidávání dalších nástrojů a obecně zvyšování složitosti s sebou nese složitější a záludnější problémy, které je třeba řešit.
Nestěžoval bych si být tebou na dlouhodobě fungující vlastnosti. Můžeš zkusit někoho přemluvit k tomu, aby do loop dopsal volitelnou podporu pro předávání TRIM. Ale to je tak všechno co se s tím dá dělat. Zajímavé by bylo zjistit, jestli se dřív tvářil LOOP jako SSD nebo jestli dřív nástroje pro různé FS začaly to SSD rozlišovat. Ale stejně si myslím, že to byly dvě nezávislé větve vývoje, které se v tomhle případě potkaly.

[Aleš Kapica]

Loop je loop. Nechápu snahu šťourat do věcí co dlouhodobě fungují tak jak mají, bez nejmenších problémů.

To že má někdo málo fantazie na to aby si dokázal představit k čemu je to dobré ještě neznamená, že to funguje blbě, nebo to není potřeba. Opravdu netoužím po tom, aby nějaký tool automaticky realizoval operaci o jakou se ho nikdo neprosil. Existují i jiné typy datového úložiště co se připojují přes loop, než lokální blokové zařízení, či soubor na lokálním FS.

[Heron]

Proto má každý slušný souborový systém možnost TRIM používat nebo nepoužívat (předpokládám, že BTRFS taky).

Nějak všichni ignorujete tu druhou větev. Tedy to, že zeroout udělá punch hole.

Tj je tu několik nezávislých věcí. Loop device se chová jako nonrotational device. FS uvnitř loopu to tedy detekuje jako ssd. Což má vliv na jeho optimalizaci vůči ne/rotačním diskům. Tohle se dá vypnout pomocí volby mountu.

Potom je tady druhý problém. Zařízení loop umí funkci discard (discard není jen vlastností ssd, i dřívější disková pole měla příkaz unmap). Tj fs v tom loopu může posílat příkaz discard do toho loop zařízení. Kde se tohle vždy interpretuje jako punch hole. Ok, v pořádku a píšu to asi po desáté, že by to mohlo být konfigurovatelné.

Jenže potom je tu další problém, že i když fs nepošle discard, ale jen pošle příkaz pro vynulování oblasti (REQ_OP_WRITE_ZEROES), tak loop device by default stejně provede punch hole.

Můžeš zkusit někoho přemluvit k tomu, aby do loop dopsal volitelnou podporu pro předávání TRIM.

Ale proč bych to měl JÁ dělat? Proč mi tady už dva lidi podsouvají něco, co jsem nikdy neřekl, nechtěl, nemyslel, nenapsal a asi 20x se proti tomu ohradil? Nikde nehovořím nic o tom, že by se mělo něco z loop device předávat na ssd. Nikde.

Celá nešťastná diskuse začala tím, zda by měl loop device zachovávat obyčejný soubor, pokud tedy není vytvořen jako sparse. Pohled do zdrojáků jasně ukazuje, že si tam vesele dělá díry a že je preferuje i před nulami. Hotovo, případ vyřešen.

[trekker.dk]

Nikde nehovořím nic o tom, že by se mělo něco z loop device předávat na ssd.

A když jsme u toho, zrovna tohle by se u toho trim dít mělo (a pokud dobře chápu, tak i děje.) Pokud něco udělá trim nad tím loop device, měl by ten trim dolézt až na to SSD (thin-lv, ceph, ...)

Pohled do zdrojáků jasně ukazuje, že si tam vesele dělá díry a že je preferuje i před nulami. Hotovo, případ vyřešen.

Když tak nad tím přemejšlím, napadá mě, že to bylo zvoleno jako efektivnější způsob (oproti zápisu těch nul), jak tam ty nuly dostat. Zbytek - že se nedetekuje, jestli ten původní soubor byl sparse, a že se to nedá konfigurovat - je podle mě ŽaVeS

[Heron]

A když jsme u toho, zrovna tohle by se u toho trim dít mělo (a pokud dobře chápu, tak i děje.) Pokud něco udělá trim nad tím loop device, měl by ten trim dolézt až na to SSD (thin-lv, ceph, ...)

Jasně, já taky neříkám, že se to dít nesmí/musí, jen jsem se k tomu vůbec nevyjadřoval, protože toto je věcí toho podkladového FS, na kterém leží onen soubor nad kterým je loop. Ten si s tím poradí po svém a bude mít pro puch hole vlastní optimalizace.

Když tak nad tím přemejšlím, napadá mě, že to bylo zvoleno jako efektivnější způsob (oproti zápisu těch nul), jak tam ty nuly dostat.

OT: když jsem si s tím teď hrál v rámci této diskuse, tak jsem testoval na zfs vynulování ZVOL, což způsobilo snížení zabrané velikosti až na výchozích 128kB. Potom jsem si všiml, že tam je zděděná komprese. Při vypnutí komprese to poctivě uchovává i ty nuly. Výchozí komprese je lz4, ale nabízí i speciální zle (The zle compression algorithm compresses runs of zeros.) Tj zfs s nulama nic nedělá a nechá to až na volitelné kompresní metodě. Tj způsobů, jak se toho zbavit a za každou cenu ušetřit místo na disku, je hodně

[Tom K]

Jen jsme se nepochopili (asi jsem to měl napsat lépe). Volitelnou podporou pro předávání TRIM jsem myslel konfigurovatelné vypnutí/zapnutí TRIM u loop device. V tom se evidentně shodneme.
A proč bys to měl dělat Ty? No proto, že bys takovou vlastnost evidentně potřeboval.
Tahle diskuse není nešťastná. Narozdíl od mnoha jiných mi přijde konstruktivní. Asi zatím nikdo nepotřeboval nastavitelný loop tak, aby nedělal díry, ale přijde mi to jako naprosto legitimní požadavek.

[Peter Golis]

Pohled do zdrojáků jasně ukazuje, že si tam vesele dělá díry a že je preferuje i před nulami. Hotovo, případ vyřešen.

To vyzerá zaujímavo, ale má to jeden drobný háčik:
TRIM pri loopback device nerobí discard pri prepise nulami.

golisp@HP-ProBook-6460b:~$ fallocate --length 8G /tmp/loopback
golisp@HP-ProBook-6460b:~$ du -sh /tmp/loopback
8.1G	/tmp/loopback
golisp@HP-ProBook-6460b:~$ losetup -f
/dev/loop13
golisp@HP-ProBook-6460b:~$ sudo losetup /dev/loop13 /tmp/loopback
[sudo] password for golisp: 
golisp@HP-ProBook-6460b:~$ sudo dd if=/dev/zero of=/dev/loop13 bs=10M status=progress
8535408640 bytes (8.5 GB, 7.9 GiB) copied, 176 s, 48.5 MB/s
dd: error writing '/dev/loop13': No space left on device
820+0 records in
819+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 180.96 s, 47.5 MB/s
golisp@HP-ProBook-6460b:~$ sync
golisp@HP-ProBook-6460b:~$ du -sh /tmp/loopback
8.1G	/tmp/loopback
golisp@HP-ProBook-6460b:~$ sudo blkdiscard -v /dev/loop13
/dev/loop13: Discarded 8589934592 bytes from the offset 0
golisp@HP-ProBook-6460b:~$ du -sh /tmp/loopback
20K	/tmp/loopback
golisp@HP-ProBook-6460b:~$ sync
golisp@HP-ProBook-6460b:~$ du -sh /tmp/loopback
8.1G	/tmp/loopback
golisp@HP-ProBook-6460b:~$ 

Takto sa mi to chová pri jadre 5.8 na rotačnom HDD, a rovnaké chovanie som mal aj na SSD. Pri prepise nulami sa nevystrieľali diery a podkladový súbor ostal v pôvodnej veľkosti. Tie diery vystrieľal až TRIM (pre zjednodušenie pomocou blkdiscard). Keď som dal takýto deravý súbor prepísať nulami cez loopback device , tak sa natiahol na pôvodnú veľkosť.

Robím snáď nejakú chybu keď mi to nefunguje podľa tvojich obáv?

[trekker.dk]

TRIM pri loopback device nerobí discard pri prepise nulami.

sudo dd if=/dev/zero of=/dev/loop13 bs=10M status=progress

Možná by bylo načase, abyste se tu přestal ztrapňovat předváděním nejenom své neschopností pochopit psaný text, ale také svými neznalostmi.

[Peter Golis]

Ja som zapisoval do blokového zariadenia vytvoreného nad súborom, nezapisoval som priamo do toho súboru. Takže podľa toho letmého rozboru jedného riadku v zdrojáku by mi vrstva loopback mala vystrieľať diery tak, aby sa scvrkol na minimum. Nestalo sa tak.

Rád sa teda dozviem prečo mi tam podľa toho letmého rozboru jediného riadku nenastalo Hole Punching. Toľko ku strápňovaniu, a nepochopeniu písaného textu. A to aj s prehľadným príkladom ktorý som sem dal.

[Tom K]

Prostým zápisem nul se nevynutí REQ_OP_WRITE_ZEROES. Na to je potřeba na souboru zavolat fallocate v režimu FALLOC_FL_ZERO_RANGE (viz man 2 fallocate). Což umí (podle mého manuálu) filesystémy: XFS,EXT4,BTRFS. Který userspace SW tohle volá netuším, ale určitě nějaký bude.
Což mohl určitě vysvětlit předřečník, ale místo toho dal raději přednost tomu vypadat jako blbec.

[trekker.dk]

Mohl, ale vzhledem k tomu, na koho jsem reagoval a jakým způsobem dotyčný diskutoval (#39, #41), mi to za to nestálo. Jak kdo vypadá, to je především otázka na toho, kdo se dívá.

[Peter Golis]

Takže sme sa od pôvodnej otázky Nebolo bezpečnejšie zavolať FSTRIM aby sa to miesto uvoľnilo dostali ku konštatovaniu že sa to tak nemá samé od seba robiť.

A že sa to už roky deje v špeciálnych prípadoch akými je zavolanie rutiny fallocate s príznakom FALLOC_FL_ZERO_RANGE, alebo v bežnejších prípadoch:

• EXT4 FS: spustí punch hole pri vytváraní FS nad súborom, nielen nad loopbackom alebo po zavolaní TRIM.
• XFS: Spustí punch hole pri vytvorení FS nad loopbackom, alebo po zavolaní TRIM (nerobí to pri vytvorení FS priamo nad súborom)
• BTRFS: Spustí punch hole až pri TRIM (nerobí to pri vytvorení FS nad súborom a ani nad loopbackom)

Tento typ chovania je tu už roky, a zatiaľ to nikomu nevadilo. Skôr naopak. Ak by toto bolo nevhodné chovanie, tak by na to bol bugreport, a bolo by to už asi aj opravené.

Ja uznávam že je tu riziko overprovisioningu. Ale to riziko preplnenia disku súvisí s plánovaním kapacity, reportovaním nárastu zaplnenia disku, a monitorovaním voľného miesta.

Takže ak sa človeku nechce plánovať, alebo vidí iné riziká overprovisioningu, tak si ten automatický TRIM kľudne môže vypnúť v crone alebo timeri. A rovnakým spôsobom môže prestač používať aj iné nástroje ktoré majú podobnú funkcionalitu. A to aj asi bolo vypnuté pri písaní tohoto blogu, inak by sa ten súbor scvrkol aj sám a nebolo by ho treba vybalancovať pred zmenšením. Jednoducho by ten podkladový súbor zaberal len miesto, ktoré reálne využíva. Teda nie pôvodných 15G alebo výsledných 7G, ale len 3G.

[Aleš Kapica]

Kristova noho. Když vytvoříš prázdný soubor o velikosti X, tak obvykle NECHCEŠ, aby se ti sám od sebe automaticky smrsknul. Souborový systém na kterém takový soubor je do toho nemá co kecat! Je to prostě alokovaný prostor a co se s ním děje je věc aplikace co s ním pracuje.

Pokud bych měl podkladový systém Btrfs a ne Ext4, tak PRVNÍ co bych udělal je vypnutí COW chování pro ten soubor, jelikož tohle je némlich to samé co virtuální disk.

A taky bych doporučoval se podívat, jak vypadá obsah souboru vytvořeného přes truncate. Ne. Nuly v něm opravdu nejsou.

[trekker.dk]

A taky bych doporučoval se podívat, jak vypadá obsah souboru vytvořeného přes truncate. Ne. Nuly v něm opravdu nejsou.

Já bych doporučoval, abyste si to zkusil sám, co by tam mělo být jiného než nuly?

$ truncate -s 128 trupokus.txt
$ hexdump <trupokus.txt 
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000080

[Aleš Kapica]

Nejsou nuly jako nuly.

[Aleš Kapica]

Tohle je u mě soubor vyplněný nulama:

~$ ls -al soubor
-rw-r--r-- 1 root root 5 pro 29 10:07 soubor
~$ cat soubor
00000~$ hexdump soubor
0000000 3030 3030 0030                         
0000005

Nuly, které vrací hexdump jsou pouze binální interpretací volného místa. Stačí místo hexdump použít od

~# truncate -s 10 soubor
~$ cat soubor
00000~$ hexdump soubor
0000000 3030 3030 0030 0000 0000               
000000a
~# cat soubor | od -a
0000000   0   0   0   0   0 nul nul nul nul nul
0000012

[trekker.dk]

Vzhledem k tomu, že se tady bavíme o FALLOC_FL_ZERO_RANGE a datech vytažených z /dev/zero, tak jste s 0x30 "nulou" úplně mimo téma. Rodíl mezi nulou zapsanou na disku a nulou z volného místa je pak pro praktické aplikace, které s tím souborem pracují, veškerý žádný.

[Jendа]

WOW Golis vs. Kapica!! Do krytu!!

[Aleš Kapica]

Mimochodem, v souvislosti s tím mne napadla pěkně hnusná forma útoku. Pokud by takový zákeřný skript přes stat načetl časy a velikost souboru, pak ho přes truncate smrsknul, následně nastavil zpět původní velikost a přes touch i původní časová razítka, tak přijdeš o data ani nemrkneš. Přišel bys na to jedině ověřením kontrolního součtu. A opravdu nevím, jestli si vůbec někdo hlídá kontrolní součty svých souborů. Řekl bych že spíš ne. U Btrfs, kde se data průběžně snapshotují, by to nemuselo tak bolet. Ale u ext4 opravdu netuším jak bych ty data, pokud by nebyla v záloze, doloval zpátky.

[Peter Golis]

Když vytvoříš prázdný soubor o velikosti X, tak obvykle NECHCEŠ, aby se ti sám od sebe automaticky smrsknul.

Ale chceš, aj keď o tom nevieš. Funkcionalita Hole Punching je už dávno hlboko zakorenená v systéme a userspace. A to nielen pri loopbacku, ale aj napriamo do súboru keďže mkfs.ext4 tie diery vystrieľal do súboru aj bez toho obávaného loopbacku.

Obavy by som pochopil na 10 ročných diskoch s mizerným IOPS kde mu dá fragmentácia poriadne zabrať. Alebo na prostrediach kde sa človek spolieha že odloží voľačo čo nechce sledovať, ale v tom prípade je to voľačo bezcenné keďže to nestojí za kontrolu.

PS: Použil som fallocate, nie truncate. To fallocate mi reálne alokovalo miesto, truncate mi alokovalo prd:

$ fallocate -l 8G /tmp/falloc; du -sh /tmp/falloc
8.1G	/tmp/falloc
$ truncate -s 8G /tmp/trunc; du -sh /tmp/trunc
0	/tmp/trunc

[Jendа]

Oni asi věděli, proč ho nepsali. Ještě by někdo chtěl, aby fungoval.

Na 4.9 takový FS šel i bez problému namountovat a dokonce i číst. Jen v okamžiku, kdy si driver sáhnul za konec zařízení, nastal kernel oops. Teď jsem to vyzkoušel na 5.8, namountovat jde, číst jde, a sáhnutí za konec zařízení už se handluje bezpečně. Jen je mrzuté, že ti to neřekne, a přijde se na to až při pokusu o čtení souboru který vyšel za konec, nebo při scrubu. Takže když uděláš chybu, tak na ni můžeš přijít až příliš pozdě (např. v okamžiku, kdy už jsi uvolněné místo něčím přepsal). Konkurenční filesystémy se nenamountují a řeknou ti proč (EXT4-fs (loop1): bad geometry: block count 256000 exceeds size of device (204800 blocks)).

[Josef Kufner]

A je to nahlášené jako chyba v btrfs?

[Heron]

Další důvod dávat btrfs na celý disk

Ale každopádně zajímavý bug.

[Aleš Kapica]

Proč asi myslíš že je LVM přežitek. Dnes dává smysl pouze multidevice.

[Heron]

Dobrej návod, ale nepřestává mě u tebe fascinovat, kolik prapodivností dokážeš zkombinovat na produkčním serveru. Produkční FS uložený na jiném FS a připojený jako loop device je prostě ... nezvyklé.

V takovém případě bych buď na prvním místě přidal další virtuální disk a tu službu rozjel na něm. Nebo kdyby to z astrologických důvodů nešlo, tak bych udělal odstávku toho serveru, shrinkl bych ten rootFS a potom bych tam vytvořil další oddíl s BTRFS a quotama a postupně bych tam migroval všechny služby toho serverů do vlastních subvolume. Nebo kdyby byl další disk politicky neprůchodný (setkal jsem se několikrát s tvrzením, že VM má mít jen jeden disk...), tak bych jej zvětšil a postupoval stejně jako v bodě 1.

Mimochodem, je to asi necelý měsíc, kdy jsem jednomu "adminovi" ukázal kouzla LVM a že pro zvětšní místa na VM není potřeba ani odstávky, že za běhu přidá další disk a vloží jej do LVM VG a jen zvětší příslušné LV. Koukal na to jak na zjevení, pokaždé zvětšil disk a laboroval s partišnama.

Já si prostě chci život udělat co nejjednodušší.

[Aleš Kapica]

Možná nezvyklé, ale funkční a bezproblémové. Testoval jsem mnohem větší harakiri. Využití loop zařízení je naprosto základní a bezproblémová věc už řadu let.

A co je další argument, který nebereš v potaz - ev. útočník v takovém případě netuší kde je a která bije, což výrazně zvyšuje moje šance abych ho sejmul dřív než napachá nějaké škody.

LVM je sice pěkné, ale přežitek.

[trekker.dk]

kolik prapodivností dokážeš zkombinovat na produkčním serveru

...

pro zvětšní místa na VM není potřeba ani odstávky, že za běhu přidá další disk a vloží jej do LVM VG a jen zvětší příslušné LV.

V jednom příspěvku Nebylo by méně prapodivné místo přidávání dalšího disku za běhu zvětšit disk stávající?