Společnost initMAX pořádá bezplatný webinář Zabbix a pokročilý databázový monitoring, zaměřený na efektivní správu a sledování databází pomocí nástroje Zabbix. Účastníci se naučí, jak nastavovat klíčové metriky, sledovat zátěž databázových serverů, analyzovat dotazy a předcházet problémům s výkonem. Webinář nabídne praktické ukázky a osvědčené postupy pro monitoring databází. … více »
Projekt reprodukovatelné openSUSE dosáhl významného milníku: proof-of-concept fork openSUSE se 100 % reprodukovatelně sestavitelnými balíčky.
Společnost Ondsel se snažila vylepšovat UX/UI FreeCADu a nabízet jej komerčně. Po dvou letech to ale vzdala. Pierre-Louis Boyer, bývalý zaměstnanec Ondselu, by rád pokračoval. Na YouTube představil soft-fork FreeCADu s názvem AstoCAD.
Aplikace pro blokování internetové reklamy v celé síti Pi-hole (Wikipedie) byla vydána v nové verzi 6. Přehled novinek a oprav v příspěvku na blogu.
Vývojáři počítačové hry Kingdom Come: Deliverance II (Wikipedie, ProtonDB) oznámili (𝕏), že za 2 týdny se prodalo 2 miliony kopií.
Společnost xAI založena Elonem Muskem na síti 𝕏 představila Grok-3, tj. novou verzi svého AI LLM modelu Grok.
Byla vydána nová verze 9.9p2 sady aplikací pro SSH komunikaci OpenSSH. Řešeny jsou 2 bezpečnostní chyby: CVE-2025-26465 (MITM pokud je zapnuta volba VerifyHostKeyDNS, ve výchozím stavu je vypnuta) a CVE-2025-26466 (DoS). Detaily na stránkách společnosti Qualys (txt).
Argentinský prezident Javier Milei čelí více než stovce žalob a trestních oznámení kvůli spáchání podvodu, protože na svých sociálních sítích propagoval kryptoměnu $LIBRA, jejíž hodnota se v krátké době znásobila a pak zhroutila.
Wayland Protocols byly vydány ve verzi 1.41. S dlouho očekávaným protokolem správy barev a High Dynamic Range (HDR).
Multiplatformní open source voxelový herní engine Luanti byl vydán ve verzi 5.11.0. Podrobný přehled novinek v changelogu. Původně se jedná o Minecraftem inspirovaný Minetest (Wikipedie) v říjnu loňského roku přejmenovaný na Luanti.
wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.13.6.tar.xz time tar xf linux-3.13.6.tar.xz real 0m6.016s user 0m5.932s sys 0m1.428s du -sh linux-3.13.6 414M linux-3.13.6TMPFS "ramdisk":
time tar xf /home/tomas/test/linux-3.13.6.tar.xz real 0m5.874s user 0m5.904s sys 0m0.616s
root@Emil:/mnt/ramdisk# time tar xfj linux-2.4.0.tar.bz2 real 0m2.345s user 0m2.340s sys 0m0.248s root@Emil:/mnt/ramdisk#
root@Emil:/mnt/tmp# time tar xfj ../ramdisk/linux-2.4.0.tar.bz2 tar: linux/drivers/net/atari_bionet.c: Cannot write: No space left on device tar: linux/drivers/scsi/FlashPoint.c: Cannot write: No space left on device tar: linux/drivers/scsi/sym53c8xx.c: Cannot write: No space left on device tar: linux/drivers/isdn/hisax/l3dss1.c: Cannot write: No space left on device tar: linux/drivers/isdn/hisax/l3_1tr6.c: Cannot write: No space left on device tar: linux/drivers/usb/usb-ohci.h: Cannot write: No space left on device tar: Exiting with failure status due to previous errors real 0m3.082s user 0m2.880s sys 0m0.508s root@Emil:/mnt/tmp#Coz je dobre. Zkusim jeste defaultni jadro, mam 3.8-trunk-amd64, mozna se tedy neco zmenilo.
Cache ma urcite vliv ale pri instalaci se pouziva take a fs nejspis nebude primountovany synchronne, ne? IMHO by system musel mit kriticky malo pameti, aby velikost cache tlacil hodne dolu.Ne, ale balickovac bude pravdepodobne dost casto volat sync, aby byl system v konzistentnim stavu, kdyby se neco pokazilo.
Nejaky napad, jak merit lepe?Napriklad pri mereni rychlosti zapisu opavdu merit dobu, nez se data zapisi na disk. Jinak se meri neco, na cem se kod FS vubec nepodili. Poradit nekomu nasazeni brtfs bez znalosti zateze mi neprijde nejlepsi napad, v tom pripade je rozhodne lepsi ext4 nebo xfs (+ pripadne LVM), protoze je mnohem mensi sance, ze dany clovek narazi na "prekvapeni".
Chci použít FS pro inkrementální zálohy - udělat snapshot, ten inkrementálně odzálohovat (tzn. přenést jen změny) na jiný stroj.
Já tohle dělám už déle než dva roky (viz článek http://www.abclinuxu.cz/clanky/btrfs-lepsi-system-souboru-praxe#inkrementalni-zalohovani-pomoci-snimku-a-rsync) a je to bez problémů.
Teď si chci (až bude v geologicky dohledné době trochu víc času) pohrát se send / receive (zbavit se rsyncu) (viz http://www.heronovo.cz/dva-zpusoby-zalohovani-snapshotu-btrfs/). Co jsem zkoušel, tak to funguje dobře a rychle, ale dlouhodobější zkušenosti ještě nemám.
Za mě tedy ano, je to dobrý nápad, jak je to spolehlivé si musí každý odpovědět sám.
Disk bude sloužit jen pro data, systém bude jinde - dávat pod Btrfs LVM je blbost, ale co MBR nebo GPT? Jsou k něčemu dobré, nebo můžu dát s klidem Btrfs na celý fyzický disk? (ve skutečnosti vzdálené diskové pole, ale o tom místní OS neví a nemusí řešit žádné RAIDy nebo spojování více disků dohromady).
Osobně to mám nad partišnou (MBR), což bych i doporučoval spíše z důvodu evidence (některé OS, když vidí prázdný disk bez partišen, tak se na něj vrhnou, ovšem pokud je tam pro ně neznámý oddíl, tak tomu dají pokoj). Zde bych tedy radil oddíl (MRB nebo GPT, je to jedno).
Od jaké verze jádra považujete Btrfs za "dost dobře použitelné"?
3 roky. (Verzi nevím.)
Komprese asi není dobrý nápad. Jsou nějaké další věci, na které si dát pozor?
Komprese je dobrý nápad, pokud člověk ví jak pracuje. Je nesmysl ji používat na oddíl s nekomprimovatelnými daty a taky na oddíl se sice komprimovatelnými daty, ale s velmi malými soubory (menšími než je blok fs, obvykle 4kiB). Ideální by tedy byly textové soubory o velikostech od 1MB a větší . Neočekávejte ale rychlejší čtení dat, očekávejte úsporu místa.
Jak s defragmentací? Radši ruční než automatická? Jak často ji spouštět?
Dříve jsem to pouštěl z cronu jednou denně, teď mám autodefrag. Větších změn jsem si nevšiml.
Jaké procento zaplněnosti disku je podle vás v pohodě a kdy už byste běželi přidávat další disky?
Staré pravidlo říká 80% zaplněnosti, ono to spíše záleží na způsobu použití. Pokud bych měl na disku převážně velké soubory vzniklé jako reflink, které se postupně zaplňují, tak bych byl i u 50% nervózní. Ale disk se dá přidat vždy.
Teď si chci (až bude v geologicky dohledné době trochu víc času) pohrát se send / receive (zbavit se rsyncu) (viz http://www.heronovo.cz/dva-zpusoby-zalohovani-snapshotu-btrfs/). Co jsem zkoušel, tak to funguje dobře a rychle, ale dlouhodobější zkušenosti ještě nemám.jj, jde mi hlavně o to send/receive, tedy zálohování na úrovni FS, ne na úrovni souborů - těch bude totiž hodně a budou malé, takže rsync by nebyl moc efektivní a zálohování by trvalo dlouho. Nejvíc mě na tom právě láká to, že FS bude vědět, co se od minule změnilo a při zálohování odešle jen ty změny a nebude se to muset znova kontrolovat soubor po souboru.
Staré pravidlo říká 80% zaplněnosti, ono to spíše záleží na způsobu použití. Pokud bych měl na disku převážně velké soubory vzniklé jako reflink, které se postupně zaplňují, tak bych byl i u 50% nervózní. Ale disk se dá přidat vždy.Soubory budou malé a budou jich řádově tisíce (většinou jednotky tisíc nebo méně) v adresáři. Těch 80 % je v pohodě, s tím jsem tak nějak počítal, stejně je potřeba držet nějakou rezervu pro případný náhlý nárůst dat.
někdy mě právě trochu znervózňuje nadávání některých lidí na Btrfs
Kdyby se měl člověk řídit podle toho, na co lidé nadávají v diskusích, tak by nemohl použít nic . Kolem fs se vedou stejné flamy jako kolem vim / emacs, kde / gnome a intel / amd apod. Hlavně to chce zálohovat, ale to platí také pro každý fs. Btrfs je stále ve vývoji a je třeba s tím počítat. Ale podle mého názoru výhody převažují (a to mám i btrfs na rootu debianu, kde opravdu aptitude rychlostně moc nevyniká; jenže aptitude není to nejdůležitější na co ten počítač mám, že jo).
Hlavně to chce zálohovat, ale to platí také pro každý fs. Btrfs je stále ve vývoji a je třeba s tím počítat.To je pravda, ale já právě zvažuji mít primární data na Btrfs a zálohovat taky na Btrfs pomocí Btrs nástrojů/vlastností...
Nebo bys taky radši zálohovat třeba XSF -> Ext4?
Ano.
Ono to samozřejmně záleží na tom, jak dalece chceme nebo můžeme zajít. V naší firmě se servery zálohují (+ je tu ještě replikace) na zálohovací server a odtud ještě na pásku (data jsou tak min. na 4 místech, pásky se po čase uloží do trezoru a koupí se další), svoje soukromá data zálohuji na druhý server a ty důležitější mám ještě na externím mediu (takže všechno 2x, něco 3x). Krom toho mám ještě většinu dat v gitu, takže na více pracovních místech.
Byl bych velmi opatrný mít všechna data na jednom FS a to ještě k tomu na FS ve stavu vývoje (přestože jsem za 3 roky neměl s BTRFS žádný problém a nikdy nedošlo ke ztrátě dat).
Tiskni
Sdílej: