Poslední příspěvky

Stran: [1] 2 3 ... 10
1
Software / Re:Nekorektní chování BTRFS
« Poslední příspěvek od RDa kdy Dnes v 19:49:29 »
Těch 700 MB nejspíš nebude volné místo v jednom kuse, ale všemožné malé kousíčky rozeseté různě po disku
O čemž si lze tak trochu udělat představu příkazem:
 btrfs inspect-internal list-chunks /path

Jedna se o 700GB - GIGABAJTU "volneho" mista.

Prikaz nic neodhalil - usage je vsude 0% - coz je divny

# head inspect-list-chunks.txt -n 12
Devid PNumber       Type/profile     PStart     Length       PEnd LNumber     LStart Usage%
----- ------- ------------------ ---------- ---------- ---------- ------- ---------- ------
    1       1        Data/RAID6     1.00MiB    6.00GiB    6.00GiB   14771  119.46TiB   0.00
    1       2        Data/RAID6     1.00GiB    6.00GiB    7.00GiB       1   37.03GiB   0.00
    1       3        Data/RAID6     2.00GiB    6.00GiB    8.00GiB       2   43.03GiB   0.00
    1       4        Data/RAID6     3.00GiB    6.00GiB    9.00GiB       3   49.03GiB   0.00
    1       5        Data/RAID6     4.00GiB    6.00GiB   10.00GiB       4   55.03GiB   0.00
    1       6        Data/RAID6     5.00GiB    6.00GiB   11.00GiB       5   61.03GiB   0.00
    1       7        Data/RAID6     6.00GiB    6.00GiB   12.00GiB       6   67.03GiB   0.00
    1       8        Data/RAID6     7.00GiB    6.00GiB   13.00GiB       7   73.03GiB   0.00
    1       9        Data/RAID6     8.00GiB    6.00GiB   14.00GiB       8   79.03GiB   0.00
    1      10        Data/RAID6     9.00GiB    6.00GiB   15.00GiB       9   85.03GiB   0.00

# grep inspect-list-chunks.txt -ve '0.00$'
Devid PNumber       Type/profile     PStart     Length       PEnd LNumber     LStart Usage%
----- ------- ------------------ ---------- ---------- ---------- ------- ---------- ------

# wc -l inspect-list-chunks.txt
134104 inspect-list-chunks.txt

(na jinem FS, kde neni RAID, ten Usage funguje spravne a odpovida ocekavanemu stavu po rebalance)

No a jak koukam sem... https://github.com/kdave/btrfs-progs/issues - 298 open issues, tak jsem tedy ZDESEN, achjo.
2
Odkladiště / Re:OSVČ a komunikace s OSPOD
« Poslední příspěvek od rmrf kdy Dnes v 19:31:53 »
Málokdo má tak veliké rozdvojení osobnosti, aby se z něj staly dvě fyzické osoby...

OSVČ, která ze zákona musí mít datovou schránku PFO, je jedna a ta samá fyzická osoba, která může mít dobrovolně také datovou schánku FO. A je to pořád ta stejná fyzická osoba, které se také může stát, že musí mít ze zákona profesní datovou schránku. To už jsou tři datové chránky pro jednu fyzickou osobu. Do datové schránky PFO ještě něco sem tam přijde, ale do profesní datové schránky nechodí tedy vůbec nic.

A to, komu kdo dává přístup do své datové schránky, je pouze jeho problém. Když ho dá někomu nedůvěryhodnému, musí si nést následky sám.
3
Vývoj / Re:Prečo nie je Lisp populárnejší?
« Poslední příspěvek od Kit kdy Dnes v 19:09:19 »
... trpěl tím, ... že je to tradičně interpretovaný jazyk, takže jeho praktická použitelnost byla omezená.

To platí jen částečně, protože program je po spuštění průběžně kompilován a následně spuštěn. Tedy rekurze jsou kompilovány pouze jednou. Samozřejmě u maker je to trochu jiné. Lisp je tedy částečně kompilován a částečně interpretován.
4
Odkladiště / Re:OSVČ a komunikace s OSPOD
« Poslední příspěvek od Filip Jirsák (forum) kdy Dnes v 18:43:55 »
To je ale řádně blbej důvod. Mělo by existovat právo na zřízení dvou schránek pokud o to požádám -- z tohohle důvodu. Ale to je tak vše. Ovšem v podání českých úředníků a lidí jako je pan Jirsák (který to tehdy nejen tady zuřivě obhajoval) je to ve výsledku zase jenom bazmek.
Aneb proč byste to dělal jednoduše, když to jde i složitě. Co kdybyste chtěl schránku jen pro FO (dříve nebyly PFO povinné) nebo jen pro PFO? Musel byste mít u té schránky nějaký příznak, zda je pro FO, PFO nebo obojí. Takže by byly čtyři varianta – jedna schránka FO, jedna schránka PFO, jedna schránka FO+PFO a dvě schránky (jedna FO, jedna PFO). Výhodu by to nepřineslo žádnou, zato by to bylo komplikovanější.
5
Vývoj / Re:Prečo nie je Lisp populárnejší?
« Poslední příspěvek od Jožka Niemand kdy Dnes v 18:32:19 »
Většina lidí má blíže k procedurálně-imperativnímu myšlení. LISP sice je multiparadigmatický, ale jeho funkcionální jádro se nezapře a tímto způsobem navržené algoritmy v něm co do elegance vynikají.
Z historického hlediska pak trpěl tím, že byl jednak rozdroben na spoustu dialektů (podobně jako FORTRAN či BASIC), jednak tím, že je to tradičně interpretovaný jazyk, takže jeho praktická použitelnost byla omezená. Neexistenci free-verze bych jako problém neviděl - jednak to není pravda, jednak napsat si vlastní interpret LISPu k osahání konceptu je v C záležitost doslova na dvě hodiny, prakticky poměrně dobře použitelný interpret pak během pár odpolední.
6
Odkladiště / Re:OSVČ a komunikace s OSPOD
« Poslední příspěvek od Martin Poljak kdy Dnes v 18:30:03 »
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.

To je ale řádně blbej důvod. Mělo by existovat právo na zřízení dvou schránek pokud o to požádám -- z tohohle důvodu. Ale to je tak vše. Ovšem v podání českých úředníků a lidí jako je pan Jirsák (který to tehdy nejen tady zuřivě obhajoval) je to ve výsledku zase jenom bazmek.
7
Software / Re:Nekorektní chování BTRFS
« Poslední příspěvek od František Ryšánek kdy Dnes v 18:02:23 »
žádný raid ti nepojede při obsazenosti 99.29% proboha

RAID pod blokovou vrstvou pojede, ten nejspíš obsazenost FS vůbec neřeší (ačkoli by mohl, pokud by dostával trim/discard).

Ale souborový systém obsazený na 99% je prakticky mrtvola, a to jakýkoli. Bejvalo pravidlo, řešit docházející místo při obsazení cca 75%, nejpozději 80%. Jinak hrozí patologická fragmentace FS a divné efekty. Taky se říká, měnit olej v autě nejlíp po 10-12 000 km, pokud ne častěji, žejo :-)

Pokud na ten disk ukládám malý počet velikých souborů, a ty soubory jednou zapíšu a pak už jenom čtu (a nejlíp je tam spíš kompostuju, než že bych je mazal), tak se bojím vyššího zaplnění o něco méně, protože metadat není tolik a fragmentace moc nemá jak nastat... přesto když se omylem dostanu přes 90%, tak se stydím :-)
8
Bazar / Re:Prodám knihy o programování v Linuxu
« Poslední příspěvek od novomente kdy Dnes v 17:36:43 »
Zdravím.

Knihy jsou prodané.

nm
9
Software / Re:Nekorektní chování BTRFS
« Poslední příspěvek od rmrf kdy Dnes v 17:30:57 »
Těch 700 MB nejspíš nebude volné místo v jednom kuse, ale všemožné malé kousíčky rozeseté různě po disku
O čemž si lze tak trochu udělat představu příkazem:
 btrfs inspect-internal list-chunks /path
10
Software / Re:Nekorektní chování BTRFS
« Poslední příspěvek od vcunat kdy Dnes v 16:57:50 »
Těch 700 MB nejspíš nebude volné místo v jednom kuse, ale všemožné malé kousíčky rozeseté různě po disku, co kde zrovna zbylo.  Obecně filesystémy (a zvláště CoW) běžně nefungují dobře, pokud jim nenecháte nějaké volné místo.  Vede to ke zvýšené fragmentaci, apod.  BTRFS používám spousty let a už 90% obsazenost mi přijde jako situace, kdy je lepší zbystřit a začít myslet na to, co se zaplněním dělat.  (Podobné zkušenosti mám s LMDB, což sice není filesystém ale DB a zase CoW.)
Stran: [1] 2 3 ... 10