Nekorektní chování BTRFS

Re:Nekorektní chování BTRFS
« Odpověď #45 kdy: 03. 11. 2025, 19:06:45 »
í o hranici 80% obsazenosti. Ze zkušeností, co mám já, tak fungují do 90% ale dál už bych nešel.

Takže ze 100 TB mohu využít jen 80 TB? Nebo 90TB?  A proč mi musí 10-20 TB ležet ladem?

Mám i 400TB pole, to mi má ležet ladem 80TB?

ano


CPU

  • *****
  • 1 194
    • Zobrazit profil
    • E-mail
Re:Nekorektní chování BTRFS
« Odpověď #46 kdy: 03. 11. 2025, 22:58:38 »

rmrf

  • ***
  • 124
    • Zobrazit profil
    • E-mail
Re:Nekorektní chování BTRFS
« Odpověď #47 kdy: 03. 11. 2025, 23:42:31 »
ano
Ne.
Btrfs je CoW, takže když má fungovat, potřebuje nějaké volné místo. Je to něco podobného, jako SSD. Btrfs se sice dá zaplnit skoro na 100%, jak máme zde uvedený příklad, ale potom se od toho nedá očekávat žádný výkon. Ta data by na tom musela pouze ležet. Ale pokud se mají točit, musí tam být přiměřený volný prostor.

Re:Nekorektní chování BTRFS
« Odpověď #48 kdy: Dnes v 00:00:31 »
To volné nedotknutelné místo prostě berte jako cenu či daň za provozování takového typu filesystému. Ať už je to btrfs, zfs, ceph a určitě ještě řada dalších...

RDa

  • *****
  • 3 122
    • Zobrazit profil
    • E-mail
Re:Nekorektní chování BTRFS
« Odpověď #49 kdy: Dnes v 00:28:27 »
ano
Ne.
Btrfs je CoW, takže když má fungovat, potřebuje nějaké volné místo. Je to něco podobného, jako SSD. Btrfs se sice dá zaplnit skoro na 100%, jak máme zde uvedený příklad, ale potom se od toho nedá očekávat žádný výkon. Ta data by na tom musela pouze ležet. Ale pokud se mají točit, musí tam být přiměřený volný prostor.

A ted nam tedy vysvetlete, proc by (specificky kvuli) CoW ten FS mel byt mene vykonny, kdyz se pouze zapisuji nova data??

U modifikace souboru (a la databaze) je snizeni vykonu jasny - namisto inplace write/update se udela kopie bloku z daneho souboru a musi aktualizovat reference ve stromu.


jjrsk

  • *****
  • 815
    • Zobrazit profil
Re:Nekorektní chování BTRFS
« Odpověď #50 kdy: Dnes v 17:35:43 »
Btrfs je CoW, takže když má fungovat, potřebuje nějaké volné místo. ... přiměřený volný prostor.
Jiste, ale urcite ne desitky nebo stovky TB ... ten prostor musi odpovidat mnoztvi zapisovanych dat, pripadne rychlosti zapisu, kterou kupodivu limituje HW, takze pokud rekneme disk zvladne nejakych 100MB/s, tak si dovolim tvrdit, ze 1GB mista (per disk) je az az.

Navic jakkoli mam btrfs pomerne rad a pouzivam ho, tak fs kterej nezvladne fungovat pri 100% zaplneni je proste rozbitej a nefunkcni. TECKA.

Proc si teda ku.va nerezervuje potrebnej prostor uz pri vytvareni FS ... ze? Viz treba problemy s rebalancem ... kdyz to ku.va vyrobi cojavim 10GB bloky, tak proc si to teda aspon JEDEN ten blok nerezervuje prave pro ucely rebalancu.

To je proste totalni fail vyvojaru. Protoze to udelat je navic zcela primitivni a jednoduchy. Prave proto ti treba ty SSDcka nedovolej vyuzit celou kapacitu, aby mely to volny misto ... zazracna technologie ze?

A to nemluvim o tom, ze samozrejme neni zadnej problem rebalanc technicky udelat i na zcela zaplnenym fs ... proste se jen prehazujou bloky dat, prace se udela v ramce a pak se to jen zapise ... . Dobre mozna to pak znamena vypnout cow, ale ta moznost tu je.

A ted nam tedy vysvetlete, proc by (specificky kvuli) CoW ten FS mel byt mene vykonny, kdyz se pouze zapisuji nova data??
Rek bych, ze cow se aplikuje i na metadata, a ty jaksi modifikujes. A rek bych, ze tohle je ten duvod, proc smazat soubor na btrfs muze trvat klidne desitky minut.