abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 3
včera 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 22
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 2
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 0
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 768 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: skutečně volný prostor na BTRFS.

19.5. 21:16 lertimir | skóre: 58 | blog: Par_slov
skutečně volný prostor na BTRFS.
Přečteno: 885×
Vzhledem k tomu, že mnozí tu používají BTRFS mnohem více než já tak se chci zeptat, Jak skutečně zjistím volný prostor na BTRFS. Moje nedávná příhoda z včerejšího dne. Nenajel mi systém do grafiky a všechno hlásilo, že není možné zapsat na filesystem. Takže ani systemd nic nezapsal. Pro mne naštěstí jsem postavil filesystem nad LVM a měl (a ještě mám) jsem v poolu trochu místa, tak jsem přidal 2G na LMV a 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.00B
tvrdi 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ě.

Odpovědi

19.5. 21:36 Vantomas | skóre: 24 | Praha
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
A na jaké verzi kernelu nebo v jaké distribuci to běží?
19.5. 21:51 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Distribuce openSUSE Thumbleweed jádro 4.5.2-1-default 64bit. Je to notebook se SSD a právě SSD byl důvod pro btrfs, jako jediného systému, který bere SSD na vědomí. Po Balnace mám df /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.00B
a
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. 06:34 FanTomas
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Aký význam ma takáto otázka???
k3dAR avatar 21.5. 11:31 k3dAR | skóre: 38
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
jednoduche, pokud nepujde o rolling release distro a/nebo kernel co vysel vcera, tak se oznaci za vinika a dinosaura uzivatel ;)
porad nemam telo, ale uz mam hlavu... nobody
19.5. 22:25 Aleš Kapica | skóre: 45 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Novější verze Btrfs tools mají ještě jeden parametr - 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).
19.5. 22:28 Sten
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
size 50.00GiB used 44.29GiB
Takž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.
19.5. 23:41 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
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.
19.5. 23:54 Aleš Kapica | skóre: 45 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Nic ve zlém, ale mám pocit, že jsi nepochopil, že Btrfs funguje zkrátka jinak než klasické FS.

Ta informace o volném místě nic neznamená, protože vždy záleží na situaci. Proto jsem ti taky napsal, že se máš podívat na kvóty. To je způsob, jak můžeš získat konkrétnější představu kolik co zabírá. Klasický výstup přes df je o ničem.
20.5. 11:11 j
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Keci v kleci ... volny misto === fyzicky dostupna kapacita disku. Ze se tam diky komprimaci mozna vejde vic, nikoho nezajima. Znamena to tak maximalne to, ze kdyz tam ulozim gigovej soubor, tak mi nezmizi giga prostoru ale min.

Osobne taky nechapu, co je na tomhle primitivne trivialnim zjisteni za problem ... ano, pak muze a bude nastavat situace, kdy fyzicky mam terovej disk, ale mam na nem ulozeno treba 1,5TB dat, ale v tom uz zadnej problem nevidim.

A totez samo plati i o snapech, reflink a dalsich ficurach ... proste jako dostupny by se melo zobrazova fyzicky nevyuzity misto na disku.
vandrovnik avatar 20.5. 11:46 vandrovnik | skóre: 15
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Btrfs sice nepoužívám, ale překvapuje mne, že neumí zjistit volné místo. Proč je to tak složité? Vždyť ten fs stejně musí interně být schopen zjistit, kolik bloků (nebo které bloky) má volné a může na ně něco zapsat, ne? Tzn. když to uživatele zajímá, nevidím důvod, aby to fs nebyl schopen říci, i kdyby to mělo znamenat třeba minutu počítání za použití nějaké utilitky.
20.5. 12:08 Aleš Kapica | skóre: 45 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Chjo.. Pokud vím, křišťálová koule do kernelu dosud implementovaná nebyla.

Kolik bloků máš volných, to vidíš, ale jestli se ti vlezou data která tam chceš zapsat, už tak jednoznačné není. Pokud převaluješ na Btrfs jeden velký soubor, tak je dobré mít minimálně tolik místa, aby se v něm mohl otočit. Se soubory které zabírají stejný objem dat takový problém mít nebudeš, protože ti stačí tolik místa, aby se na něm otočil jen ten největší z nich.

A volné místo potřebuješ i při odstraňování souborů - i když to lze obejít přes truncate.
vandrovnik avatar 20.5. 12:15 vandrovnik | skóre: 15
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
A tazateli nestačí ty volné bloky? Že se soubor z x důvodů pak nemusí vejít, i když by to zpočátku podle volného místa vypadalo, že se vejde, to je jasné. Měl jsem za to, že si ale naříká, že vidí volné místo 25 % kapacity, a přitom už skoro žádné volné místo nemá.
20.5. 12:54 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Jestli ono to nebude spíš tak, že takovéhle nějaké hausnumero 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.
vandrovnik avatar 20.5. 14:05 vandrovnik | skóre: 15
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
No to právě působí dojmem, že se jen někomu nechtělo to doprogramovat. Zrovna v případě Raid 1 by asi nebylo tak složité zjistit, kde je těch volných bloků nejméně. 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ď.
20.5. 15:24 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Nedostatek znalostí často vede k tomu, že má dotyčný dojem, že všichni ostatní jsou hlupáci, a on by to udělal daleko lépe, jenom kdyby to uměl. Ovšem je dobré neplést si dojmy a pojmy.

Why is free space so complicated?
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. 15:56 Vantomas | skóre: 24 | Praha
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Takže jsi nikdy nedal du -sh . na jednom místě a potom df -h na druhém a na základě toho se rozhodl, zda lze zkopírovat/přenést adresář z jednoho místa na druhé?
Heron avatar 20.5. 16:40 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
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. 17:22 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
S tímhle plně souhlasím. Porovnávat du a df nemá cenu. A taky souhlasím s tím, že volné místo X rozhodně neznamená, že vždy tam zapíšu X. 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 co tu jistotu podrývá je situace, kdy mně FS hlásí, že má 12GB volno a přitom tam nezapíšu ani sektor, a ani když to píše systémový log, který normálně by psal i když uživatel už nemůže. (to je poměr horší než 10^(-6)*X) Přitom samozřejmě ten FS musí vědět, že příští požadavek na zápis nemůže splnit.

Jak to tedy hlídáte vy? Nějaký triger, který mě automaticky pošle zprávu, že se btrfs ať již z jakéhokoli důvodu blíží zaplnění. (To je pro mne primární funkce nač používám df. Kouknu se a když má disk obsazenost přes 85% něco s ním začnu dělat.) Tady jsem držel obsazenost pod 80% a myslel si, že to stačí. A zbytek si btrfs uřídí. Zase pracovat s ním tak že to budu držet na 40% se mi nechce. To bych dělal na serveru, kde volnost místa zrychlí operace, ale ne na notebooku, kde zátěž disku je malá a primárně jde o to, mít v něm všechny data, které potřebuji.
Heron avatar 20.5. 17:40 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Je otázkou k čemu vlastně došlo. Pokud to bylo jen ono klasické, že btrfs neměl žádné volné chunky (ty jsou po 1GB), tak tam stačí pustit jen 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.00B
Aktuá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.)

20.5. 18:02 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
To je dost jiná situace. Tohle je root filesystem na SSD. velikost ted 50GB ( a už jsem 2krát prihazoval z LVM protože se to kouslo.) na tom je opensuse Thumbleweed (tedy rolling release distro) aktualizace jsou díky rolling velké, někdy 1GB týdně. suse aktualizace opleská snapshoty viz výpis snapperu
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=no 
to 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.
Heron avatar 20.5. 18:13 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
No to je to. Otázkou je, jestli je ten systém připraven na to, že tam bude neustále několik málo až žádný chunk volný. Asi ne příliš. Přidat 2 (slovy dva) chunky na vyřešení problému, no neznám příliš jiných systémů pro ukládání dat, které by byly ze dvou alokačních jednotech úplně happy. S tímto osobně nemám zkušenost, já btrfs používám (od počátku) na jednotky TB.
20.5. 20:22 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Dva LVM stripy byly první 4GB a druhy 2GB. Takže to zase tak málo nebylo. Ale volno nikdy nekleslo pod 10 GB což je cca 20% volno, to není tak málo.
21.5. 11:23 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.

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.)

USE="-gnome -kde";turris
22.5. 10:22 trubicoid2
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
neni na to nejaky skript pro cron? zjisti rozdil a pusti balance s nejakym procentem

moc casto to asi cenu nema poustet, dost dlouho to trva i kdyz vlastne nic neudela
20.5. 18:13 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
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.
20.5. 21:13 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
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.
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í.
20.5. 17:44 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
A jak to hlídáš ty? Mě je v podstatě jedno, co kde kolik zabírá. To co mne zajímá je indikovat s předstihem situaci, do které jsem se dostal, tedy situaci: "Je tam málo místa, nezapíšeš." Stejně tak jako na serverech mohu monitorovat (a monitoruji) disky muninem, xymonem nebo nagiosem a když přesáhne zaplnění zvolenou hranici dostanu zprávu a něco s tím udělám. Tady teď jsem od systému nedostal informaci. Jak jsem už psal jednou. držel jsem zaplněnost pod 80% s tím, že jsem se domníval, že to stačí, že rozdělení dalšího prostoru si FS udělá. Ale nestačí. Kde je tedy hranice? Jak máš nastavit server, aby sis ho nemusel všímat a měl jsi jistotu, že ti zahlásí, když se FS bude blížit situaci, kdy nezapíše? A jestli stvoříš skript, který z těch různých příkazů vyzobá v jednotlivých částech fs poměry alokovaného a celkového prostoru a vezme ten nejhorší, tak mne přirozeně napadne a proč to neudělá ten FS přímo.
20.5. 18:16 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
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“?
20.5. 21:09 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
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. 07:16 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Když jsem postupně vzpomínal jaké FS jsem na různých systémech používal tak to bylo ještě JFS a oba Reisery. Ve všech byla informace o volném místě na v podstatě monotoní klesající funkce v závislosti na zapsaném objemu, která limitně mířila k nule při vzrůstajícím zápisu do filesystému. (Ve všech kromě btrfs.) A úbytek volného prostoru při zápisu souboru o velikosti X byl něco mezi 100-120% X. A minimálně na XFS, Ext3 a Reiserovi jsem nějaký čas provozoval některý disk jako "archivní read only", čímž myslím, že jsem do něj napsal "co to šlo" tedy na 1TB disku zbyl volný prostor pod 2MB. Tedy zaplněnost 99,9995%, pak jsem jej přemountoval Read only a používal. A při tomto zápisu FS pocitivě hlásil kolik má volno, pak jsem zapsal půlku dat, podíval se co to udělalo a kolik volného prostoru zbývá a pokračoval. To není až tak podstatné, ale podle mne všechny FS, co jsem potkal, kromě btrfs, oznámí férovou odpovídající informaci jako volné místo.
Heron avatar 21.5. 11:53 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
BTRFS není pokračovatelem řady extX, JFS, XFS, Reiser. Ano, na všechny výše zmíněné fs lze zapisovat soubory, ale tím veškerá podobnost končí. Je to úplně jiný druh zvířete (jak rád říká Martin Mojžíš).

BTRFS se používá ve chvíli, pokud mají pojmy jako multidevice, COW, reflinky, subvolume, snapshoty pro toho uživatele nějaký význam a bude je skutečně používat. Jinak z toho prakticky nic nemá (až dejme tomu na checksum) a získá jen o něco pomalejší fs u kterého navíc bude překvapen, že vyžaduje nějakou další údržbu (mimochodem úplně stejné, jako vyžadoval např. PostgreSQL ve verzích ještě bez procesu autovacuum). Za pár let tyto udržovací funkce budou automatické.

Takže tak. Radu, jak zaplnit btrfs na 99.99995% nemám a ani si nemyslím, že je to smysl existence btrfs. Smysl existence btrfs je udělat kopii 1TB dat do 1s, předat to userspace k používání a současně ze storage device krom metadat neukousnout ani blok navíc.

Pokud potřebuješ provozovat fs na malém storage (kde malé je malé z hlediska počtu 1GB chunků), tak si zvol některý z výše uvedených fs (třeba xfs, u kterého se za poslední roky událo mnoho skvělých optimalizací výkonu).

21.5. 12:29 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
BTRFS jsem v tomto případě použil z jednoho prostého důvodu. JE to jediný FS, který v designu ví, že je provozován na SSD a podle toho se chová. A CoW FS je z principu, jak fungují SSD pro ně mnohem přátelštější, než standardní přepisování na místě. A druhý důvod byly zmíněné snapshoty kolem aktualizací. Nejde mi zaplnění FS na 99,99%.

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. Pak musím 10 minut řešit, jak ho zprovoznit, abych se dostal k podkladům, které potřebuji. Což pokud máte někdy jednání může být mnoho času a značná nevýhoda. Nechat mu "dost volného místa" mi připadalo jako dobré řešení, ale jak vidět nestačí to. V první větě odpovědi, na kterou Filip Jirsák dal odkaz a používá ji pro argumentaci, jak to vlastně nejde se píše: "If everything is RAID-1 (or RAID-0, or in general all the same RAID level), then yes, we could give a sane and consistent value from df." A to je přesně případ, který mám. Jeden oddíl, jeden konzistentní RAID (a to žádný nebo RAID 0 na jednom disku) přes všechny subvolumy. Přesto si nemyslím, že pro situaci, kdy df napíše 10GB volno a rootový proces nezapíše se hodí označení. "sane a consistent value form df."

Možná to rozumně nejde uřídit a BTRFS má smysl používání spíše na větších objemech dat. Možná jeho výhoda na SSD proti jinému FS vlastně není velká. A také používám btrfs na 4 dalších místech v objemech 2TB a více bez jakých koliv problémů, ale ty jsou mnohem méně dynamické v zápisu než to SSD s roling release.

21.5. 16:05 Aleš Kapica | skóre: 45 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
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.
k3dAR avatar 21.5. 16:39 k3dAR | skóre: 38
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
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 [...]
Ja ti nevim, ale neni #0 (a cele toto vlakno) prave proto ze se mu presne tohle stalo? ;-)
porad nemam telo, ale uz mam hlavu... nobody
21.5. 17:47 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Ne, není. Dotaz i celé tohle vlákno je o tom, že si lertimir bůhví proč myslel, že když je na disku volné místo, automaticky to znamená, že na něj root může zapsat. Což není pravda ani u btrfs, ani u jiných souborových systémů zmiňovaných zde v diskusi.
k3dAR avatar 21.5. 20:01 k3dAR | skóre: 38
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
fakt? :) a co je tohle? Moje nedávná příhoda z včerejšího dne. Nenajel mi systém do grafiky a všechno hlásilo, že není možné zapsat na filesystem.

jinak u ostatnich souborovych systemu se asi nestane ze mas volne 10GB a neprovede se ani:
echo "Filip Jirsak for president of Universe" | sudo tee UzTiHrabe.txt
porad nemam telo, ale uz mam hlavu... nobody
21.5. 20:11 Aleš Kapica | skóre: 45 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
No to ale spíš vypadá jako jiný problém. Btrfs (ale i jiné FS, např. ext4) se brání vzniku potenciální nekonzistence tím, že se fs remountne jako read only. Každopádně to, že nejde zapsat ani ťuk není rozhodně způsobeno tím, že by došlo místo. Doporučil bych se kouknout co říká dmesg.
22.5. 01:23 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Pokud by to bylo nekonzistencí a RO mountem, bylo by to dobré. Ale přihození +2G na LVM a resize btrfs na max schopnosti zápisu obnovily, bez remountu a bez rebootu. Bohužel dmesg je pouze do rebootu a notebook od té doby už rebootnutý byl a aktuálně v té situaci jsem na zkoumání neměl čas, potřeboval jsem primárně funkční komp. Ale téma se už vyčerpalo. Jak monitorovat btrfs vedle zaplnění (tedy myslím to co napsat do skriptu pro cron s jakými parametry a podmínkami pro zaslání varování) se zřejmě nedozvím. Ale tvoje poznámka, že to v podstatě normální není, a zjistit (v této chvili už jen pro příště.) jestli FS není v nekonzistentním stavu mi připadá nejvíce smysluplná ze všech, které tu zazněly.
21.5. 21:08 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
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 nestane
Stane, příkladů už tady v diskusi bylo napsáno dost.
21.5. 20:14 Atom321 | skóre: 20
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
To se ale hluboce mýlíte. To, že při 20% volného místa root nemůže zapsat, nastává u normálních FS jen v extrémních situacích - např. na ext3 pokud dojdou volné i-nody. U BTRFS se to ale stává celkem běžně. To (stejně jako lertimir) považuju z uživatelského hlediska za hrubou závadu.
21.5. 20:56 Aleš Kapica | skóre: 45 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Ale jdi ty. Používám Btrfs už pěkně dlouho, ale tohle se mi stalo jen když byl problém s blokovým zařízením. Ovšem nebylo to proto, že by byl FS plný, ale proto že se remountnul do ro stavu. Ovšem to v takovém případě udělá každý slušný FS.
21.5. 21:55 Atom321 | skóre: 20
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
To byl ale ovšem zcela jiný případ. Tady se bavíme o situaci, kdy FS hlásí spoustu volného místa, ale při zápisu vrátí chybu "není volné místo".
Situace popsaná autorem dotazu nastává zřejmě i jiným uživatelům. Tenhle dotaz nevidím zdaleka poprvé. Dokonce se dostal i do FAQ. Viz např.:

http://askubuntu.com/questions/464074/ubuntu-thinks-btrfs-disk-is-full-but-its-not
https://coreos.com/os/docs/latest/btrfs-troubleshooting.html
https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21
https://wiki.archlinux.org/index.php/Btrfs#Displaying_used.2Ffree_space
21.5. 22:34 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
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?
21.5. 22:45 Atom321 | skóre: 20
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
V tomto zcela jiném případě, kdy se bavíme o remountu do read-only, vrací chybu EROFS.
22.5. 08:39 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Pokud je systém v read-only režimu, je logické, že kernel jako důvod chyby zápisu uvádí, že systém je v read-only režimu. Vám se ale nelíbilo, že systém hlásí ENOSPC chybu v případě, kdy jsou vyčerpány zdroje souborového systému. Mne by zajímalo, jakou jinou chybu by měl podle vás hlásit.
21.5. 21:06 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Ano, v různých situacích, z pohledu FS extrémních, dochází k tomu, že nejde na disk zapsat. Lertimir na jednu takovou situaci narazil. Kdyby mu na ext3 došli volné i-nody, budeme tady úplně stejně diskutovat o ext3 a o hrubé závadě, že mu to 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.
21.5. 22:15 Atom321 | skóre: 20
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
On ten problém nastává i jiným lidem, než panu Lertimirovi. Je to dokonce popsané ve FAQ (psal jsem to jinde v této diskusi).

Normální uživatel prostě očekává, že když mu Krusader píše "20GB" volno, tak se tam ten 10KB konfigurák vejde. Pak přijde pan Machr Nejchytřejší, začne tvrdit že uživatel je debil a má si pustit tuten magický příkaz pro zjištění velikosti metadat, pak támhleten pro jejich vybalancování a případně ještě jiný pro defragmentaci. To se nezlobte, v 21. století očekávám, že tohle si ten filesystém vyřeší sám. Pokud ne, tak je to buď nedodělek, nebo hrubá chyba v návrhu/implementaci. Na nedodělku by nebylo nic špatného, stačí to jen přiznat.

A srovnávat to s nedostatkem inodů na ext3, tedy s problémem zděděným z Unixů ze sedmdesátých let ... tomu nerozumím, neměl být BTRFS moderní systém, který tyto prastaré neduhy řeší?
21.5. 22:27 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
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).
21.5. 23:58 Atom321 | skóre: 20
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
On ten problém nastává i jiným lidem, než panu Lertimirovi.
Samozřejmě.
Ovšem nastává zjevně výrazně častěji, než na jiných FS.
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.
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á.
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.
Ne, očekávám, že si svoje vnitřní struktury vybalancuje automaticky a nebude čekat na příkaz administrátora.
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í...
Zde si dovolím citovat z BTRFS Wiki:

Btrfs is a new copy on write (CoW) filesystem for Linux aimed at implementing advanced features while focusing on fault tolerance, repair and easy administration.

Obávám se, že v případě Lertimira tyto cíle naplněny nebyly, tedy alespoň poslední z nich.
22.5. 08:55 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
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 dva
Ješ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.
21.5. 09:15 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
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é inode
No vidíte, takže to víte, že ani jiné souborové systémy vám nedají jedno číslo, které říká vše.
20.5. 04:34 Sten
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Pomocí 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.
20.5. 08:13 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
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.
20.5. 12:21 drunkezz | skóre: 32 | blog: kadeco
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.

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. 12:57 Vantomas | skóre: 24 | Praha
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
To jsou ale výmluvy. Ten FS ví, jestli nějaký subvolume nebo dokonce jen nějaký soubor je v jedné nebo ve více kopiích. Provede to takovouhle analýzu a pak čím jednodušší má user pool, tím lepší výsledky to může podat. Pak taky může btrfs ze všech stran nutit administrátora aby nastavil pro různé subvolumy třeba kvóty, tím dostane btrfs taky informaci o tom kolik místa asi tak potřebuje, aby uspokojil požadavky jednotlivých subvolume. A RAID na úrovni souborů, tak to už bych asi zanedbal, tam ať to ukazuje duchařinu, s tím už se nedá moc dělat.

Nikdo nechce aby to volné místo bylo známé do posledního bytu, ale bohatě stačí nějaký reálný odhad a jestli btrfs někde musí věštit z koule, tak ať nějak prudí správce, aby tolik věštit nemuselo.
Heron avatar 20.5. 16:48 Heron | skóre: 50 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Pak taky může btrfs ze všech stran nutit administrátora
A nebylo by vhodnější, aby ten administrátor věděl s čím pracuje?
20.5. 20:18 Sten
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Jak jsem psal výše, v tomto případě šlo zřejmě o bug, kdy metadata neexpandovala, když data měla spoustu volného místa, a bylo potřeba sáhnout po rebalance. AFAIK je tento bug již opraven. Pokud nenarazíte na podobný bug, fungují ty odhady celkem slušně.
20.5. 21:43 pavele
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Prostě používáš nevhodné zastaralé linuxové distro se zatuchlým kernelovým jádrem a starým btrfs, v nejnovějším jádru jsou tyto chyby už dávno opravené.

Pak se nesmíš divit těmto dávno opraveným bugům. Btrfs vlastnosti jako checksum pro každý soubor a CoW jiné zastaralé fs neobsahují. Také používáš tento fs naprosto nevhodným způsobem (používáš ho). :-)
21.5. 11:35
Rozbalit Rozbalit vše Re: skutečně volný prostor na BTRFS.
Když se o takové věci nedokážou dohodnout odborníci, jak to mají používat laici? Zřejmě to pro ně není. ext2,3,4 zdar...

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.