Poslední příspěvky

1

Software / Re:Nekorektní chování BTRFS

« Poslední příspěvek od RDa kdy Dnes v 14:48:29 »

žádný raid ti nepojede při obsazenosti 99.29% proboha

A to ma jakoze jaky duvod? Je tam 700 GB volneho mista. Proc to misto tedy neni dostupno? (tentokrat to uz mistem v metadatech omezeny fakt neni).

2

Vývoj / Re:Prečo nie je Lisp populárnejší?

« Poslední příspěvek od Kit kdy Dnes v 14:33:18 »

Tu je slavny komiks a tri policka su venovane aj LISPu a nieje to happyend :-)
https://toggl.com/blog/save-princess-8-programming-languages

Je smutné, když ostatní programátoři vidí na Lispu jen ty závorky.

3

Studium a uplatnění / Re:Lze podnikat v IT?

« Poslední příspěvek od Tomáš Procházka kdy Dnes v 14:22:47 »

mi se libil napad na vyuziti dronu v doprave, ze by na strese auta byl dron a pred krizovatkou, neprehlednou situaci by vyletel a objlidnul situaci vepredu a poslal fotky a analyzu situace. ale bezne drony jsou jeste dost pomale a asi by nestihly nekam zaletet a vratit se nez by tam clovek dojel autem.

Takhle jsem na dovolené natáčel jízdu v úzkých serpentinách. Bylo to super, ženě jsem hlásil, že to tam může v klidu poslat a klidně si i najet.
Problem byl, že jsme brzy vystoupali více než 150m, což se počítá od místa vzletu, ne výšky terénu. Takže mě pak SW dále nepustil.

4

Odkladiště / Re:OSVČ a komunikace s OSPOD

« Poslední příspěvek od Ondřej Surý kdy Dnes v 14:17:54 »

A není to jenom OSPOD. Pokud máte auto registrovat na FO (a nikoli na PFO/OSVČ), tak pokuty taky budou chodit poštou nikoli do datovky, atd...

5

Software / Re:Nekorektní chování BTRFS

« Poslední příspěvek od Miroslav Buček kdy Dnes v 14:12:33 »

žádný raid ti nepojede při obsazenosti 99.29% proboha

6

Software / Re:Nekorektní chování BTRFS

« Poslední příspěvek od RDa kdy Dnes v 13:48:58 »

BTRFS je porad nekorektni ... aktualni stav:

Overall:
    Device size:                 130.97TiB
    Device allocated:            130.93TiB
    Device unallocated:           40.11GiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                        129.98TiB
    Free (estimated):            738.63GiB      (min: 721.92GiB)
    Free (statfs, df):           738.59GiB
    Data ratio:                       1.33
    Metadata ratio:                   3.00
    Global reserve:              512.00MiB      (used: 0.00B)
    Multiple profiles:                  no

Data,RAID6: Size:97.85TiB, Used:97.16TiB (99.29%)
   /dev/***0   16.31TiB
   /dev/***1   16.31TiB
   /dev/***2   16.31TiB
   /dev/***3   16.31TiB
   /dev/***4   16.31TiB
   /dev/***5   16.31TiB
   /dev/***6   16.31TiB
   /dev/***7   16.31TiB

Zapisovat do pole jde jenom do tech UNALLOCATED jednotek, tj. muzu tam zapsat 40GB * 6/8 (protoze raid 6)

Ale kdyz se podivas na data usage - 99.29% ze zhruba 100TB, to dela 0.7% = 700 GB "volneho mista".

Prakticky ale to vetsi volne misto ktere vesele btrfs propaguje je nedostupne - cela ta vec se "zasekne" (jede to jednotky kB/sec). Proc? To nikdo nevi.

Pro uvolneni do Unallocted pouzivam balance s -dusage=95, minulej vikend jsem nechal projet -dusage=98, ale zadny efekt, byt to presouvalo par dnu data. Tak nechapu co to vlastne delalo - ale logicky vzato, efekt to mit nemuze, pokud mam 99.29% usage, tak balance by musel byt pusten zrejme s -dusage=100.

Celkove je pro me zahada - proc se prakticky neda vyuzit volne misto v existujicich alokacich.

Jakoze COW vytvari kopie, ale ta STARA verze je pri nulovem poctu referenci prece uvolnena (to je tech nedostupnych 700GB), pokud by se na ni vazala nejaka reference (ze snapshotu, ktere zde ted nejsou), tak se to prece nebude pocitat mezi FREE space.

Pak je zde faktor neskutecne pomalosti - vi se vubec jak BTFFS pouziva RAID6 ? tj. jaky je tam stripe/chunk size?? Jestli to nahodou nema nejaky wtf write amplification factor, ze by to prepocitalo gigabajty dat, i v pripade ze je zamer zapsat par kilo.

Jsem s tim jako velice nespokojeny - ze je primarni alokacni politika "vyplacat vsechny unallocated jednotky", namisto toho, aby to zapisovalo do volneho mista, ktere alokovano je - je duvodem tedy ta neefektivita RMW procesu? nebo to RMW neni vubec dovoleno a kazdy chunk (6GiB dostupny, 8*1GiB na discich) je povazovan za SMR-like zone, tj. ma to write/append, ale vubec to tedy neumi modify? (jakoze COW si s tim vystaci, ale... pak chybi efektivni zpusob defragmentace, protoze ani balance -dusage=100 se mi zda ze neprovede presne to co, co by se melo udit).

7

Software / Re:Nekorektní chování BTRFS

« Poslední příspěvek od Miroslav Buček kdy Dnes v 12:32:07 »

Je to klasická btrfs ENOSPC past, ne „mystická“ chyba.

Co se stalo:
   1.   Došly metadata, ne data.
Metadata, RAID6: total=134.62GiB, used=134.11GiB (99.63%) – tedy metadata plná. Když jsou metadata plná, btrfs přestane zapisovat a remountne se RO, i kdybys měl ještě stovky GB v Data. Proto zároveň vidíš:
space_info DATA has 131499511808 free, is full – to znamená „uvnitř datových block group je pár volných děr, ale já z nich teď nic neudělám“, ne že je disk fyzicky plný.
   2.   Btrfs si v tu chvíli už neumělo vytvořit nový metadatový chunk.
Aby si mohl přidat 1GB metadat v RAID6, musí mít nealokovaný prostor na zařízení. Ty jsi měl všechno alokované do datových chunků, takže nebylo kam ten nový metadatový chunk dát. Proto ti i balance na začátku spadl s No space left on device.
   3.   find ti zapisoval.
Říkáš „read-only úloha“, ale na btrfs (a u 42M souborů zvlášť) to není čisté čtení – aktualizuje se atime / relatime a tím se zapisují metadata. Když jsou metadata na 99,6 %, každý takový zápis tě dorazí. Řešení: mountovat s noatime (případně aspoň relatime zkontrolovat) na takovém objemu souborů.
   4.   Po smazání pár desítek GB to stále nešlo, dokud jsi neudělal balance ... -dusage=10.
To je správně – mazání uvolní místo logicky, ale ne vždy v chunku, který potřebuješ. Balance ti přerovnal data tak, že vznikl nealokovaný prostor → btrfs si pak mohl zvětšit metadata → vše se odblokovalo. Přesně tohle je ta „btrfs headroom“ vlastnost.
   5.   Proč to neudělá automaticky?
Tvoje očekávání je rozumné („když metadata dojdou, tak si udělej kousek místa sám“), ale btrfs to v tomhle rohu neumí bezpečně udělat samo – zvlášť u RAID6 profilů, které jsou i v roce 2025 pořád citlivější než RAID1/10. Raději abort transakce + RO, než aby sahal do všech datových BG a přerovnával bez tvého vědomí.

Co z toho plyne pro provoz:
   •   Nenechávat pole dojet na 100 % alokace. U tak velkého FS (8×14 TB, 40+ M souborů) klidně nechat 1–2 % zařízení nealokované.
   •   Cron balance, třeba:

btrfs balance start -musage=50 -dusage=5 /mnt/...

nebo i agresivněji podle chování.

   •   noatime na mountu.
   •   Monitoring btrfs fi usage a hlavně metadata – jakmile jsi nad ~95 %, řešit.
   •   Při mkfs si v zásadě nevynutíš “hodně metadat dopředu” v tom smyslu, jak bys chtěl; můžeš volit profil (--metadata raid6), ale to už máš. To, co ti fakt pomáhá, je mít nealokovaný kus + pravidelně balancovat.

Takže: není to, že by btrfs byl úplně „nekorektní“, ale jo – je to nepříjemný, málo zdokumentovaný roh btrfs, který u velkých, hodně souborových, RAID6 polí vyleze. Tvoje diagnóza „došla metadata a neměl si kam šáhnout pro nový chunk, dokud neproběhl balance“ je přesná.

8

Odkladiště / Re:OSVČ a komunikace s OSPOD

« Poslední příspěvek od makovec_3 kdy Dnes v 12:30:28 »

Napíšu to jednodušeji: OSPOD je povinen s vámi komunikovat na občanské adrese (pokud máte datovou schránku jako "fyzická osoba" tak na ní) a neměl by na adrese provozovny (datová schránka "podnikající fyzické osoby"). Prostě vám dopisy posílají na adresu bydliště, a ne do práce.

Důvod toho oddělení těch schránek v principu je že k té schránce podnikající osoby mohou mít oprávněný přístup další autorizované osoby (účetní), zatímco ta osobní je z principu věci jenom vaše.

9

Vývoj / Re:Prečo nie je Lisp populárnejší?

« Poslední příspěvek od alobalova_ciapocka kdy Dnes v 09:49:45 »

Tu je slavny komiks a tri policka su venovane aj LISPu a nieje to happyend :-)
https://toggl.com/blog/save-princess-8-programming-languages

10

Odkladiště / Re:OSVČ a komunikace s OSPOD

« Poslední příspěvek od Filip Jirsák (forum) kdy Dnes v 09:01:25 »

Existuje více druhů datových schránek. Pokud podnikáte jako fyzická osoba (OSVČ), máte povinně zřízenou datovou schránku podnikající fyzické osoby (DS PFO). Přes tu s vámi budou úřady komunikovat v souvislosti s podnikáním.

Vedle toho si jako občan můžete dobrovolně založit datovou schránku fyzické osoby (DS FO). Přes tu s vámi budou úřady komunikovat v případech souvisejících s vámi jako občanem – např. byste tam dostal pokutu za překročení rychlosti.

Orgán sociálně-právní ochrany dětí (OSPOD) s vámi bude komunikovat jako s občanem (nedovedu si představit důvod, proč by s vámi komunikoval jako s podnikatelem), takže pokud máte datovou schránku fyzické osoby (DS FO), bude s vámi komunikovat přes datovou schránku.

Obecně pro orgány veřejné moci platí, že pokud má subjekt, se kterým chtějí komunikovat, zřízenou datovou schránku, musí mu úřední dokumenty zasílat prostřednictvím datových schránek – pokud to povaha dokumentu nevylučuje.

Tj. pokud máte příslušnou datovou schránku, OVM je vždy musí použít (pokud to nevylučuje povaha dokumentu, že by do datové schránky poslat nešel). Záleží ale na tom, zda máte odpovídající datovou schránku, tedy pro občanské záležitosti datovou schránku fyzické osoby (DS FO).