Portál AbcLinuxu, 23. dubna 2024 21:24
btrfs filesystem resize max / změtšil filesystem a pak systém znovu běžel. Ale problém je v tom, že df vypisuje/dev/mapper/system-root 52428800 37737980 13663684 74% /(a před zvetšením také tvrdil, že má přes 10G volno) a stejně tak
btrfs filesystem df / Data, single: total=42.61GiB, used=31.16GiB System, DUP: total=32.00MiB, used=16.00KiB Metadata, DUP: total=2.88GiB, used=2.17GiB GlobalReserve, single: total=512.00MiB, used=0.00Btvrdi teď pro data že total - used je více než 9G a
btrfs filesystem show /
Label: none uuid: 318424ab-b633-454e-8d04-b0c0c551d9f1
Total devices 1 FS bytes used 33.87GiB
devid 1 size 50.00GiB used 44.29GiB path /dev/mapper/system-root
také indikuje dost místa. (možná se ucpala ta část Metadata tam vypadá malá rezerva).
Pročítam dokumentaci a zkusím btrfs balance.
Ale tady vidím to co jsem minule v diskusi nazval arogancí vývojářů. Pokud by v této chvili df a jiný způsob dotazu na prostor ohlásil, že je plno tak na to uživatel zareaguje. Ale to že standardní nástroje ohlásí že je volné místo, ale není možné zapsat je chybně.
/dev/mapper/system-root 52428800 37726800 13663984 74% /
btrfs filesystem df / Data, single: total=31.75GiB, used=31.16GiB System, DUP: total=32.00MiB, used=16.00KiB Metadata, DUP: total=2.88GiB, used=2.16GiB GlobalReserve, single: total=512.00MiB, used=0.00Ba
btrfs filesystem show /
Label: none uuid: 318424ab-b633-454e-8d04-b0c0c551d9f1
Total devices 1 FS bytes used 33.32GiB
devid 1 size 50.00GiB used 37.56GiB path /dev/mapper/system-root
nicméně pomerně malý přesah na metadata zůstal.
21.5.2016 11:31
usage:
root@stroj :~# btrfs fi usage /opt
Overall:
Device size: 100.00GiB
Device allocated: 58.02GiB
Device unallocated: 41.98GiB
Device missing: 0.00B
Used: 55.23GiB
Free (estimated): 42.77GiB (min: 21.78GiB)
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 16.00MiB (used: 0.00B)
Data,single: Size:56.01GiB, Used:55.22GiB
/dev/mapper/data-pisek 56.01GiB
Metadata,DUP: Size:1.00GiB, Used:4.08MiB
/dev/mapper/data-pisek 2.00GiB
System,DUP: Size:8.00MiB, Used:16.00KiB
/dev/mapper/data-pisek 16.00MiB
Unallocated:
/dev/mapper/data-pisek 41.98GiB
root@stroj :~# btrfs device usage /opt
/dev/mapper/data-pisek, ID: 1
Device size: 100.00GiB
Data,single: 56.01GiB
Metadata,DUP: 2.00GiB
System,DUP: 16.00MiB
Unallocated: 41.98GiB
root@stroj :~# btrfs fi df /opt
Data, single: total=56.01GiB, used=55.22GiB
System, DUP: total=8.00MiB, used=16.00KiB
Metadata, DUP: total=1.00GiB, used=4.08MiB
GlobalReserve, single: total=16.00MiB, used=0.00
Jinak pokud chceš mít ještě podrobnější přehled o tom kolik které subvolume zabere, tak si zapni kvóty (viz).
size 50.00GiB used 44.29GiBTakže metadata mají spoustu místa, kam mohou expandovat. Ve starších verzích jádra tam IIRC byl bug, který občas způsobil, že se metadata nechtěla roztahovat, pokud měla data ještě spoustu volného místa. Rebalance to vždy spravil.
btrfs fi usage vypíše přesnější odhady. Bohužel způsob, jakým btrfs funguje, neumožňuje nějak spolehlivě počítat volné místo. Že standardní nástroje hlásí volné místo, ale nejde zapsat, se může stát v mnoha jiných případech (kvóty, SELinux, rezervy, problémy NFS ap.) a programy by na to měly být připraveny.
btrfs fi usage vypíše přesnější odhady. Bohužel způsob, jakým btrfs funguje, neumožňuje nějak spolehlivě počítat volné místo.
To je podle mne arogantní nesmysl a neochota se zamýšlet nad tím, co uživatel potřebuje. Vždyť pomocí toho fi usage se přesnější odhad dostane, takže ten FS ho ví. A ví, že mu někde dochází deskriptory, nebo prostor v nějaké tabulce nebo buhví co. Tak proč to neoznámí tím, že pošle malé číslo prostoru. To že ten údaj je nepřesný nebo podceněný je mnohem méně důležité. Když mi FS hlásí že má volný 2% tak se budu chovat jinak než když má 30% volno. Kdysi na Win jsem nějakou dobu používal kompresované oddíly a tehdy také s volným místem hlásil v podstatě odhady. jpeg sebral jiné místo než stejně velký txt, ale mělo to proporci. To co je podstatné, že tady i v situaci, kdy na pokus zapsat FS zahlásí, že není možné a na dotaz standardním prostředkem je li volné místo zahlásí jo, je 20% fs volné. Když si představíš programátora, tak to mnohdy uděláš tak, že se zeptáš jestli je místo třeba statvfs a pokud ano, pak zapíšeš. A teď dostaneš informaci, že máš tolik volno a pokus skončí s chybou. Jako na hlavu. Podle mne kdyby místo takto špatného odhadu, hlásili minimum, co jde zapsat, bylo by to mnohem jednodušší.
Že standardní nástroje hlásí volné místo, ale nejde zapsat, se může stát v mnoha jiných případech (kvóty, SELinux, rezervy, problémy NFS ap.) a programy by na to měly být připraveny.To je sice pravda, nicméně méně z toho platí pro roota na rootovém FS.
20.5.2016 11:46
df vrací, a pak se uživatelé právě diví, že tam zapsat nejde. Když budete mít disky třeba v RAID1, můžete na jednom disku mít spoustu volných bloků, ale nezapíšete už nic.
If you have a really good idea for how to make it simple for users to understand how much space they've got left, please do let us know, but also please be aware that the finest minds in btrfs development have been thinking about this problem for at least a couple of years, and we haven't found a simple solution yet.
Nejvíc to volné místo stejně bude vrtat v hlavě lidem, co mají jednoduchou konfiguraci (Raid 1 ze dvou disků apod.), a tam by mohly být výsledky asi o poznání lepší, než jsou teď.Problém ale není v tom, že by uživatelé dostávali nepřesné výsledky, problém je v tom, že uživatelé přikládají číslům jiný význam, než ta čísla mají. Takže řešením není vyvěštit taková čísla, která by lépe odpovídala mlhavým představám uživatelů, řešením je naučit uživatele chápat, jak jejich systém funguje. Oni totiž uživatelé většinou chtějí vědět, zda ten a ten uživatel může do toho a toho adresáře zapsat soubor o takové a takové velikosti – a místo toho se ptají na volné místo. Na tu první otázku je možné odpovědět. Pokud je odpověď na druhou otázku kladná, odpověď na první otázku to stejně nedává.
20.5.2016 16:40
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
du -sh . na jednom místě a potom df -h na druhém
Přesně tohle jsou hodnoty, které si uživatelé vykládají špatně, jak píše Filip. To, že du na jedné straně ukáže nějaké číslo a toto číslo je menší, než df na straně druhé, vůbec neznamená, že se tam ta data skutečně vejdou. A to ani u klasických systémů souborů. Dokáže s tím zamávat už jen velikost bloků na cílové straně.
Některé systémy souborů mají prográmky (třeba xfs_estimate), které dopředu řeknou, kolik místa budou na daném systému souborů zabírat konkrétní data.
20.5.2016 17:40
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
btrfs balance start -dusage=0 (což znamená udělej balance bloků, u kterých je zaplnění daty 0% - tedy vlastně si je jen označí jako volné, podobně -musage=0 pro metadata) a je to.
Jak to tedy hlídáte vy?Já to fakticky nehlídám nijak. Sem tam se podívám na
btrfs fi show a btrfs fi df a pokud mi připadá příliš velký rozdíl mezi alokovaným a skutečně zabraným místem, tak pustím balance:
Data, single: total=6.67TiB, used=6.16TiB System, DUP: total=40.00MiB, used=784.00KiB System, single: total=4.00MiB, used=0.00B Metadata, DUP: total=23.00GiB, used=8.70GiB Metadata, single: total=8.00MiB, used=0.00B GlobalReserve, single: total=512.00MiB, used=0.00BAktuálně je tedy alokován prostor pro 6.67TB data, zatímco je jich tam 6.16TB, a 23GB pro metadata z 8 potřebných. Vzhledem k tomu, že ten svazek má 8TB, tak to řešit netřeba. Btrfs má dostatek místa pro nové chunky a také má dostatek místa v alokovaných chunks. Kdybych to chtěl řešit, tak spustím
btrfs balance start. (Stejně se to jednou stane součástí toho fs a nebude třeba tyto servisní úkony pouštět extra.)
snapper ls Type | # | Pre # | Date | User | Cleanup | Description | Userdata -------+-----+-------+--------------------------+------+---------+--------------------+-------------- single | 0 | | | root | | current | pre | 397 | | Fri Apr 22 19:11:04 2016 | root | number | zypp(zypper) | important=yes post | 398 | 397 | Fri Apr 22 19:14:34 2016 | root | number | | important=yes pre | 403 | | Sat Apr 30 01:19:26 2016 | root | number | zypp(zypper) | important=yes pre | 404 | | Tue May 3 21:22:46 2016 | root | number | zypp(zypper) | important=yes pre | 405 | | Tue May 3 21:40:52 2016 | root | number | zypp(zypper) | important=yes pre | 406 | | Tue May 3 21:55:54 2016 | root | number | zypp(zypper) | important=no post | 407 | 406 | Tue May 3 22:09:11 2016 | root | number | | important=no pre | 408 | | Sun May 8 14:11:05 2016 | root | number | yast sw_single | post | 411 | 408 | Sun May 8 21:14:46 2016 | root | number | | pre | 412 | | Sun May 8 21:14:48 2016 | root | number | yast online_update | post | 413 | 412 | Sun May 8 21:15:57 2016 | root | number | | pre | 414 | | Sun May 8 21:16:40 2016 | root | number | zypp(zypper) | important=no post | 415 | 414 | Sun May 8 22:05:20 2016 | root | number | | important=noto všechno beru, že mu to nedělám jednoduché. Ale ta neproporcionalita prázdného místa je hrozná. Když by třeba byla nějaká konfigurační direktiva, která by nastavila, co vlastně btrfs reportuje do df, tak si nastavím nejvíce konzervativní možnost a budu spokojeny. Mnohem raději budu, když mi nahlasí že jsem 10 GB dat zabral 35GB prostoru a mám zaručených 15. Paráda. Když by tohle co se oznamuje bylo na konfigurační direktivě je to super.
20.5.2016 18:13
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
lvm a na tom, btrfs zrovna neni nejstastnejsi reseni ...
A u openSUSE bych se spis podival na nastaveni snapperu .. výchozí nastavení není příliš dobré co se týče uklízení nepotřebných snapshotů.
Díky čemuž často dojde místo i u zdánlivě prázdného disku.
.. Kdyžtak `snapper list` a pak `snapper delete x-y` ( pozor nikdy nemazat snapshot 0 a 1.)
Ale to, co očekávám, je nějaká proporcionalita. Tedy když FS mi píše, že má volno X, tak očekávám, že s nějakými daty tam tedy bych X mohl zapsat, ale že mnohem větší pravděpodobnost, tam zapíšu 0,2 * X a skoro jistotu, že tam zapíšu 0.01 * X.To ale očekáváte špatně. Protože když je na disku volné místo X, vůbec to neznamená, že jste nevyčerpal kvótu, a nezapíšete už ani bajt.
Přitom samozřejmě ten FS musí vědět, že příští požadavek na zápis nemůže splnit.Ne, FS to nemůže vědět. FS neví, který uživatel a kam se bude pokoušet zapisovat. FS nemůže vědět, že příští požadavek na zápis bude smazání souboru, takže i když je disk zaplněn do posledního bajtu, příští zápis projde.
Jak to tedy hlídáte vy?Jak hlídáme co? Z diskuse už by mělo být jasné, že hlídat volné místo na disku nedává smysl, protože to číslo neznamená nic zajímavého.
Až na to, že celý dotaz je neschopnosti zapsat systémovými programy běžícími pod rootem. To že se uživatel může dostat do jiných mezí je přirozeně také možné, ale v tom zakopaný pes není.Ale to, co očekávám, je nějaká proporcionalita. Tedy když FS mi píše, že má volno X, tak očekávám, že s nějakými daty tam tedy bych X mohl zapsat, ale že mnohem větší pravděpodobnost, tam zapíšu 0,2 * X a skoro jistotu, že tam zapíšu 0.01 * X.To ale očekáváte špatně. Protože když je na disku volné místo X, vůbec to neznamená, že jste nevyčerpal kvótu, a nezapíšete už ani bajt.
které jsem se dostal, tedy situaci: "Je tam málo místa, nezapíšeš."No a jste si jistý, že jste se opravdu dostal do téhle situace? Nebylo by lepší hlídat třeba situace „blíží se vyčerpání některého ze zdrojů souborového systému“?
Nebylo by lepší hlídat třeba situace „blíží se vyčerpání některého ze zdrojů souborového systému“?A na btrfs to pohlídám jak? Na všech ostatních systémech co jsem používal což byly XFS a postupně Ext2,3,4 stačilo hlídat volné místo. Na to mít nastavené triggery a pokud to nebyl skutečně zvláštní případ kdy bylo několik milionu malých souborů a bylo potřeba ještě hlídat volné inode. rád se poučím a nechám na systemu pravidelně proběhnout skript, který posoudí zdroje a varuje mne.
21.5.2016 11:53
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Jde mi v principu o to, jak rozumně pohlídat BTRFS, abych se vyhnul situaci, když přijdu na jednání otevřu notebook a on nenabootuje, protože rootové procesy nemají v rootovem FS kam psát.Tak zrovna tohle se ti u Btrfs nestane, protože ti zkrátka nedovolí zaplácnout veškerý volný prostor - má vyhrazený prostor, do kterého nedovolí zápis, takže když se ti zaplní Btrfs disk, tak po restartu normálně najedeš. Ovšem pokud nezačneš situaci řešit, tak zase brzy skončíš se zaplněným diskem - což se projeví tak, že na něj nelze zapisovat, ale číst se z něho dá, takže systém jinak pojede. Minimální kapacita pro Btrfs začíná od 1GB. Jinak čím více místa má k dispozici, tím lépe. Je proto pitomost ho škrtit přes LVM, pokud nepotřebuješ mít zároveň ještě nějaké jiné speciální oddíly. Já používám Btrfs v notebooku, v režimu raid1 nad dvěma ssd disky několik let - žádný swap. Původně to byly 2x60GB OCZ, pak 2x120GB Samsung a teď je to 2x256GB mSATA. Řadič pro ně má velikost jako 2,5 palcový disk, takže opět používám i DVD mechaniku. Předtím jsem měl druhý ssd disk umístěn místo ní. Zaplnit disk na 90% znamená, že ti už nezbyde moc místa na kterém se budou převalovat data. Zbytečně si tak budeš to ssd huntovat, protože se data budou neustále převalovat jen přes 10% čipů. Ale nikdy jsem se nedostal do situace, že bych kvůli tomu nenabootoval.
Ja ti nevim, ale neni #0 (a cele toto vlakno) prave proto ze se mu presne tohle stalo?Jde mi v principu o to, jak rozumně pohlídat BTRFS, abych se vyhnul situaci, když přijdu na jednání otevřu notebook a on nenabootuje, protože rootové procesy nemají v rootovem FS kam psát.Tak zrovna tohle se ti u Btrfs nestane, protože ti zkrátka nedovolí zaplácnout veškerý volný prostor [...]
echo "Filip Jirsak for president of Universe" | sudo tee UzTiHrabe.txt
fakt? :) a co je tohle?To je právě ukázka toho, v čem se Lertimir mýlil.
jinak u ostatnich souborovych systemu se asi nestaneStane, příkladů už tady v diskusi bylo napsáno dost.
při zápisu vrátí chybu "není volné místo"Jakou jinou chybu by měl kernel vrátit než
ENOSPC? Jakou vrací chybu, když na ext4 dojdou i-nody?
df neukázalo na velikosti volného místa. Z uživatelského hlediska je chyba používat souborový systém, jehož vlastnosti dotyčný nezná, a hlavně myslet si, že volné místo na disku je číslo, které o stavu souborového systému říká vše.
On ten problém nastává i jiným lidem, než panu Lertimirovi.Samozřejmě.
Normální uživatel prostě očekává, že když mu Krusader píše "20GB" volno, tak se tam ten 10KB konfigurák vejde.To očekává špatně. Důvodů, proč to nemusí projít, už bylo v diskusi popsáno spousta.
To se nezlobte, v 21. století očekávám, že tohle si ten filesystém vyřeší sám.Jistě. Třeba ten filesystém brnkne administrátorovi, aby zvýšil kvótu.
Pokud ne, tak je to buď nedodělek, nebo hrubá chyba v návrhu/implementaci.A nebo ten souborový systém prostě má jiné cíle, než všechno vyjádřit jedním jediný číslem.
neměl být BTRFS moderní systém, který tyto prastaré neduhy řeší?Ne. Btrfs je moderní systém, který přináší spoustu nových možností, které třeba ext[2-4] nemají. Některé lidi to bohužel nezajímá, a mylně se domnívají, že „moderní souborový systém“ znamená, že ho prostě nainstalují, a Btrfs bude dělat zázraky. Chyba není v tom souborovém systému, ale v nesmyslných očekáváních. Svá očekávání můžete opakovat kolikrát chcete, ale vlastnosti souborového systému tím nezměníte. Reálné možnosti jsou dvě – buď si zjistíte, co Btrfs doopravdy umí, a tomu přizpůsobíte svá očekávání. A nebo můžete zkusit najít jiný souborový systém, který vašim očekáváním vyhoví (akorát se obávám, že bude záviset na jedné špatně dostupné periferii – křišťálové kouli).
Ovšem nastává zjevně výrazně častěji, než na jiných FS.On ten problém nastává i jiným lidem, než panu Lertimirovi.Samozřejmě.
Zachytil jsem jen dva: kvóty a nedostatečný počet inodů. Kvóty uživatel očekává jen na discích, kde jsou nastaveny, což není tento případ. Vyčerpání inodů je možnost čistě teoretická.Normální uživatel prostě očekává, že když mu Krusader píše "20GB" volno, tak se tam ten 10KB konfigurák vejde.To očekává špatně. Důvodů, proč to nemusí projít, už bylo v diskusi popsáno spousta.
Ne, očekávám, že si svoje vnitřní struktury vybalancuje automaticky a nebude čekat na příkaz administrátora.To se nezlobte, v 21. století očekávám, že tohle si ten filesystém vyřeší sám.Jistě. Třeba ten filesystém brnkne administrátorovi, aby zvýšil kvótu.
Zde si dovolím citovat z BTRFS Wiki:Pokud ne, tak je to buď nedodělek, nebo hrubá chyba v návrhu/implementaci.A nebo ten souborový systém prostě má jiné cíle, než všechno vyjádřit jedním jediný číslem ... buď si zjistíte, co Btrfs doopravdy umí, a tomu přizpůsobíte svá očekávání...
Ovšem nastává zjevně výrazně častěji, než na jiných FS.S tím, že je to zjevné, bych byl opatrný. Navíc nemám pocit, že by to něco znamenalo. U aut také nastává mnohem častěji než u jízdních kol problém, že dojde benzín, ale nikdo to nevnímá jako jejich zásadní nevýhodu.
Zachytil jsem jen dvaJeště zde padlo minimálně to, že se zbývajícím prostorem na zařízeních nelze garantovat vlastnosti nakonfigurovaného RAIDu.
Vyčerpání inodů je možnost čistě teoretická.Ve většině případů. Stejně jako je ve většině případů čistě teoretická možnost, že vyčerpá volné chunky. Když o tom omezení na počet i-nodů někdo nebude vědět a zrovna se mu je podaří vyčerpat, bude překvapen a naštván úplně stejně, jako teď Lertimir, který nevěděl o způsobu alokace a podařilo se mu vyčerpat volné chunky.
Ne, očekávám, že si svoje vnitřní struktury vybalancuje automaticky a nebude čekat na příkaz administrátora.To je ovšem vaše chyba, že očekáváte něco, co ten systém v žádném případě nezaručuje.
Obávám se, že v případě Lertimira tyto cíle naplněny nebyly, tedy alespoň poslední z nich.Obáváte se špatně. Easy administration je něco jiného, než no administration. Dokonce je to často protichůdné. No administration máte třeba ve Windows, což je důvod, proč tam není žádné easy administration. Funguje tam například to, že si systém něco sám udělá automaticky a nečeká na příkaz administrátora – naopak administrátor a uživatel čekají, až si systém vyřídí své věci a oni budou moci dál pracovat. Protože systém na rozdíl od administrátora netuší, že si vybral naprosto nevhodnou dobu.
A na btrfs to pohlídám jak?Myslím, že už to tu psal Heron.
Na všech ostatních systémech co jsem používal což byly XFS a postupně Ext2,3,4 stačilo hlídat volné místo.Pokud pro vás nejdůležitější vlastností souborového systému je to, že jeho celkový stav vyjadřuje jedno číslo (což mimochodem není pravda ani u vámi zmíněných), asi by bylo rozumné používat některý z těch všech ostatních systémů.
bylo potřeba ještě hlídat volné inodeNo vidíte, takže to víte, že ani jiné souborové systémy vám nedají jedno číslo, které říká vše.
fi usage nedostanete přesnější odhad. Dostanete více čísel ukazující stav různých částí a k tomu odhad „Free (estimated)“. Ten zobrazuje to samé číslo jako df.
Když si představíš programátora, tak to mnohdy uděláš tak, že se zeptáš jestli je místo třeba statvfs a pokud ano, pak zapíšeš. A teď dostaneš informaci, že máš tolik volno a pokus skončí s chybou. Jako na hlavu.Úplně stejně to dopadne, pokud mezi zjištěním volného místa a zápisem zapíše jiný program. A z mnoha dalších důvodů. Pokud takhle nějaký programátor uvažuje, je chyba na jeho straně – a jeho program nebude fungovat v moha různých případech, málo místa na disku je jen jeden z moha spouštěčů. Mimochodem, když bude takový programátor jenom přepisovat data v souboru, bude si nejspíš myslet, že k tomu žádné volné místo na disku nepotřebuje. Jenže v případě CoW souborových systémů to není pravda.
So, in general, it is impossible to give an accurate estimate of the amount of free space on any btrfs filesystem. Yes, this sucks. If you have a really good idea for how to make it simple for users to understand how much space they've got left, please do let us know, but also please be aware that the finest minds in btrfs development have been thinking about this problem for at least a couple of years, and we haven't found a simple solution yet.
https://btrfs.wiki.kernel.org/index.php/FAQ#Understanding_free_space.2C_using_the_original_tools
D.
20.5.2016 16:48
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Pak taky může btrfs ze všech stran nutit administrátoraA nebylo by vhodnější, aby ten administrátor věděl s čím pracuje?
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.