Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Řešení dotazu:
Radíš nepoužívat HW raid, takže MD a nad tím LVM?Z mého pohledu je md spolehlivější než hw řadič. Pokud není potřeba speciálních vlastností FS, tak pro KVM virtuálky je LVM a LV dobrá volba.
Nebo místo toho ZFS nad debianem?Se ZFS na linuxu nemám žádné zkušenosti. Na BSD to používám pro jaily (kontejnery). Pokud by jsi šel do ZFS na linuxu, tak je vhodné použít ZVOL (já to používám zatím jen jako backend pro iscsi). Možná ještě někdo poradí něco dalšího. Nevím, jak jsou na tom dneska formáty typu QCOW2 apod., mělo to umět různé stupně klonování a snapshotů a thin provisioning, ale jak je na tom dneska nevím.
LVM rychle snapshoty?Rychlé pořízení.
je tam velky perfhit nad zatizenymi VMMá to pomalejší zápisy, ale pokud je dostatečná rezerva výkonu na storage, tak to pořád stačí. Tohle se musí vyzkoušet, zda to pro dané nasazení stačí.
Jeste k te kombinaci DRBD a Proxmox.Já o kombinaci nehovořil, proxmox neznám. Nasazení DRBD bylo vždy easy.
Když potřebuješ udělat DRBD resize, zvětšíš LV a každé straně a uděláš resizeKdyž mohu zvětšit LV, mám již pod ním dost prostoru. Varianta A: zvětším disk X, disk Y, zvětším příslušná LV na straně X, na straně Y a zvětším DRBD pro jednotlivá LV Varianta B: zvětším disk X, disk Y, zvětším jedno drbd na obou stranách a poté na primary drbd zvětšuji LV dle potřeby. Mně přijde varianta B jednodušší, ale možná jsem něco přehlédl...
Mít jedno velké DRBD pole je zvířecí, Jde to, funguje to, ale jakákoliv operace (např. kontrola FS) pak neskutečně dlouho trvá - ostatně, jako u každého velkého FS.FS je věc LV, ne? Takže kontrola FS probíhá stejně jen na části drbd, kterou zabírá příslušné LV/FS. Jak více drbd tu kontrolu urychlí? Mně pro dva stroje přijde více drbd nad LVM místo naopak zbytečné, ale jak říkám, třeba jsem něco přehlédl.
DRBD - pro každý virtuál a blokové zařízení samostatné.Akorát pozor na to, kdyby těch virtuálů mělo být hodně nebo měly víc oddělených disků - maximální počet DRBD zařízení na jednom stroji je AFAIK pořád 250.
obyčejný HBA bez writeback cacheAno.
právě tu zálohovanou writeback cacheTak až (až, ne jestli) selže, tak good luck s opravou. Jeden řadič se neobtěžoval informovat o nedostatečné kapacitě baterky (takže po výpadku proudu prostě selhala), další 3 řadiče se baterkou odrovnaly sami do 14 dnů od zakoupení (naštěstí ve zkušebním režimu), protože dodavatel zkompletoval řadič tak, že baterku připojil projistotu s opačnou polaritou. (Ano, vůbec to nebylo ošetřeno na konektoru, jak by jeden čekal.) Jo a taky jednou přišel řadič už s dopředu s komplet vybitou a tedy zničenou baterkou (asi mu to leželo v regále dlouho).
Ve scénářích s větším množstvím malých zápisů (PostgreSQL s vyšší zápisovým provozem) má writeback cache naprosto zásadní vliv, fsync() nemusí čekat na potvrzení od disku, stačí uložení do RAM controlleru, který to pak může seskládat do větších transakcí.Toho se dá docílit i jinak. Hned v prvním komentáři jsem hovořil o tom, že WAL lze umístit na SSD, u postgresu lze snadno umístit i jednotlivé objekty (tabulky, indexy) nad jednotlivé disky (rychlejší, pomalejší, podle potřeby). Nehledě na další optimalizace, pokud je lze použít (synchronous_commit, commit_siblings).
Alternativní cesta k urychlení zápisů je asi ZFS a write intent log na flash úložišti, ale s tím zatím nemám zkušenost.V našich testech bylo ZFS s logem na SSD hodně rychlé, zkušenosti z produkce ale také nemám.
Ve skutečnosti žádné takové složitosti, o jakých píšete a píše se tady v diskusi, nepotřebujete. I průměrný HW řadič v serveru zvládne v dnešní době zapisovat rychlostí 600 - 900 MB/s v závislosti na prostředí, číst ještě rychleji. Testováno na Dell PowerEdge R730 (řadič H730 PERC mini, 4 x HGST HUH721010AL4200 v RAID6), na Dell PowerEdge R630 (řadič H730P mini, 4 x Seagate ST1000NX0453 v RAID10) a na Dell PowerEdge R430 (řadič PERC H730, 4 x ST2000NM0005 v RAID5), a za použití NFS exportu po 10GbE nebo 40GbE (tam teprve poznáte omezení pole, nikoliv sítě...)
Pokud chcete virtualizovat via KVM, mohu rozhodně doporučit kombinaci HW RAIDu a LVM s přímou propagací jednotlivých LV virtuálním strojům (přes virtio). Co do výkonu jsme nic lepšího pro KVM nenakonfigurovali, a nemusíte řešit žádnou vrstvu souborového systému - až tu ve virtuálních strojích.
Pokud nedůvěřujete jako někteří jiní diskutující HW RAIDu od renomovaných výrobců, pak byste pravděpodobně dle stejné logiky měl přestat důvěřovat brzdám ve vašem autě nebo výtahu ve vašem domě. Ano, obojí už v historii selhalo a občas selže i dnes, ovšem na počet uskutečněných jízd se jedná o naprosto zanedbatelné riziko.
Ne, SSD opravdu není kouzelná hůlka Harryho Pottera. Jsme u serverů, ne na desktopu. Tudíž pokud jsou vaše SSD připojené na SATA sběrnici, a HDD na SAS, tak SSD budou z principu zapisovat i číst pomaleji. Stále však mějte na paměti režii a omezení virtuálního hardware a ovladačů k němu - VirtIO nikdy nebude rychlé jako bare-metal instalace, a poznáte to zvlášť ve Windows virtuálních strojích (což se vás asi ale netýká).
Pokud máte čas a chuť experimentovat, vaše skladba disků přímo vybízí k tomu "odložit" OS hypervisoru na RAID 1 z těch SSD, a ze zbytku namísto RAID 10 stvořit 3x RAID 1, a "rozstripovat" si mezi ně všechno "ručně" pomocí 3 VG v LVM - ať už si rozdělíte jednotlivé virtuálky, nebo oddíly ve virtuálkách. Je to pro gurmány a fajnšmekry, ale v důsledku je možné, že dosáhnete mnohem vyššího výkonu než na hotovém RAID10 - a také efektivnější redundance. Nehledě na to, že zdaleka ne každý řadič umí adaptivně rozšiřovat RAID10 - kdybyste to někdy v budoucnu náhodou potřeboval.
K výkonu ještě pár obecných poznámek - pokud máte "heavy loaded" databázový stroj, nevirtualizujte ho. A už vůbec mu neemulujte disky pomocí COW souborů, tam je skutečně jediná možnost - RAW oddíly. Zkušenost říká, že pokud vám něco zcela obyčejného bude chodit ve virtuálu pomalu, nejsou problémem diskové operace (IOPS), ale CPU, paměť nebo samotná aplikace. A konečně - stále platí základní fyzika = chcete-li výkon, musíte si ho zaplatit v hardware - žádný zázračný typ RAIDu, souborového systému nebo čarodějného rozložení dat už na věci nic zásadního nezmění.
Ted nevím jak dál ve virtuálkách. Dát LVM a na oddíli BTRFS? Někde jsem čet, že to může být pomalé, ale byl jsem zvyklý mít dksky např. filmy s kapacitou 100G, fotky 50GB atd. Umí to BTRFS, nebo je nutno použít kvoty nebo jak to řešit?BTRFS má subvolumes. Pokud je nutno omezit velikost, tak na subvolume lze aplikovat quotu, ale s tím jsem si nikdy nehrál. Dávat btrfs na lvm je blbost, tj popírání jedné z vlastností btrfs. Se subvolumy lze dělat snapshoty, send; sdílí se volné místo (klasický problém s LVM, v oddílu na filmy je 50GB volného, ale ty jsou potřeba v oddílu na projekty). Takže na virtuálky bych dal už jen čisté BTRFS (pochopitelně se zamyšlením se nad využitím daného fs, třeba na db server bych to nedal, dělat cow nad cow (mvcc architektuře) je přece jen pomalejší - na druhou stranu se to ale dá vypnout pomocí chattr na konkretní adresář a instalátor pg v debu už to tak nastavuje automaticky).
Jinak jak tu někdo poznamenal, ty SSD jsou pomalejší než to pole s terabitových disků. Pole čte nějakých 650MB/s ssd pouze 450MB/s.Tj sice hezké, ale sekvenční rychlost není vše. Klasický 7200rpm disk dá v náhodném přístupu nějakých 0.5MB/s (7200rpm / 60 = 120; 120*4kB = 480kB/s). I nejobyčejnější SSDkčo v náhodném přístupu dá 40MB/s, což je 80x tolik co rotační disk. Toto je hlavní výhoda SSD.
Mě se to sice zatím nestalo, ale občas tu jsou přibhy s restaurování dat s BTRFS.Zpravidla od těch co s ním nemají absolutně žádnou zkušenost.
btrfs qgroup limit …
). Když pak někdo přijde s dobrým důvodem, že potřebuje 50 GB navíc, tak mu hejbneš kvótou a všichni jsou spokojení.
U svého desktopu zálohuju jednou za čas ručně na domácí server,..Pokud si myslíš, že to je vyhovující řešení, tak ti nebudu brát iluzi. Jenom si zkus dělat na papír čárky pokaždé, co si na to vzpomeneš a odzálohuješ. Zákon schválnosti je v tom, že ti to zdechne just těsně předtím co si na to po delší době vzpomeneš. No a pak se ještě zamysli nad tím, co všechno by ve tvém případě znamenalo dostat se do původního stavu, jak dlouho by to trvalo a kolik by to tak cca stálo času a peněz.
na stránkách BTRFS jsem četl, že když bude nad LVM, tak je pomalejšíTo je pěkná kravina. LVM ti akorát rozdělí disk na logické bloky. Na rychlost FS, co bude nad ním to nemá žádný vliv. Leda že bys snad měl to LVM v nějakém raidu. Pak ti to bude logicky brzdit replikace dat.
Performance raw partitions are slightly faster than logical volumes btrfs does write optimisation (sequential writes) across a filesystem subvolume write performance will benefit from this algorithm creating multiple btrfs filesystems, each on a different LV, means that the algorithm can be ineffective (although the kernel will still perform some optimization at the block device level)Navíc jak píše Heron je to vrstva navíc. Docela mě přesvědčil, že vše co udělám přes lvm udělám i BTRFs. Už jsem tedy nainstaloval na virtuálku pouze 1 partition s BTRFS, ale to lze stále ještě změnit.
..lze stále ještě změnitKdyž jsem zrovna nedávno stěhoval taliánovi data, tak jsem nejprve na externí mašině překopíroval jeden jeho disk, ale zbytek (přesun ostatních dat a následně konverze na raid1) se už pak realizoval za běhu u něj na kompu, aniž by ho to rušilo v práci. Akorát byl nutný restart, protože ty původní disky bylo nutné postupně z té jeho bedny vykuchat a nahradit – neměl šuplíky, ani koš.
convert between RAID1 and RAID5, between RAID5 and RAID6, between RAID0, RAID4, and RAID5, and between RAID0 and RAID10 (in the near-2 mode).Nic proti btrfs (ač jej nepoužívám, vyhovuje mi víc zfs). Jen aby nedošlo k nedorozumění..
Pišou tam toto:To není nic specifického pro btrfs, podobné optimalizace mají i ostatní filesystémy.
Mě se použití qcow2 nelíbí z toho důvodu, že to přidává další dvě vrstvy navíc.Souhlas. (Až na ten pravopis teda.)
virt-install --name rac1-2 --ram 16384 \ --os-type=linux \ --os-variant=ol5.11 \ --disk path=/vm/rac1-2_01.qcow2,format=qcow2,bus=virtio,size=60 \ -c /mnt/iso/Oracle/OEL/OEL-5U11-V47133-01.iso \ --network bridge=br0-lan,model=virtio,mac=RANDOM \ --network bridge=br1-ha,model=virtio,mac=RANDOM \ --graphics vnc,password=heslo,listen=0.0.0.0,port=5900 --noautoconsole \ -v --vcpus=12 \ --boot cdrom,hd# NFS3 (host OEL7) :
192.168.0.3:/vol_ssd_rac on /mnt/ssd type nfs (rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.3,mountvers=3,mountport=635,mountproto=udp,local_lock=none,addr=192.168.0.3) [root@hv-rac1 ssd]# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75 test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64 fio-2.2.8 Starting 1 process test: Laying out IO file(s) (1 file(s) / 4096MB) Jobs: 1 (f=1): [m(1)] [100.0% done] [22596KB/7440KB/0KB /s] [5649/1860/0 iops] [eta 00m:00s] test: (groupid=0, jobs=1): err= 0: pid=3681: Fri Sep 22 01:01:27 2017 read : io=3071.7MB, bw=23706KB/s, iops=5926, runt=132681msec write: io=1024.4MB, bw=7905.6KB/s, iops=1976, runt=132681msec cpu : usr=1.31%, sys=3.78%, ctx=414454, majf=0, minf=26 IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0% issued : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0 latency : target=0, window=0, percentile=100.00%, depth=64 Run status group 0 (all jobs): READ: io=3071.7MB, aggrb=23706KB/s, minb=23706KB/s, maxb=23706KB/s, mint=132681msec, maxt=132681msec WRITE: io=1024.4MB, aggrb=7905KB/s, minb=7905KB/s, maxb=7905KB/s, mint=132681msec, maxt=132681msecNFS3 (guest OEL5)
192.168.0.3:/vol_ssd_rac on /mnt/ssd_rac type nfs (rw,nfsvers=3,addr=192.168.0.3) [root@back-rac1 ssd_rac]# fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75 test: (g=0): rw=randrw, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64 fio 1.57 Starting 1 process test: Laying out IO file(s) (1 file(s) / 4096MB) Jobs: 1 (f=1): [m] [100.0% done] [38436K/13025K /s] [9384 /3180 iops] [eta 00m:00s] test: (groupid=0, jobs=1): err= 0: pid=3540 read : io=3072.9MB, bw=32867KB/s, iops=8216 , runt= 95736msec write: io=1023.2MB, bw=10944KB/s, iops=2735 , runt= 95736msec cpu : usr=1.04%, sys=4.54%, ctx=1503280, majf=0, minf=20 IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0% issued r/w/d: total=786645/261931/0, short=0/0/0 Run status group 0 (all jobs): READ: io=3072.9MB, aggrb=32867KB/s, minb=33656KB/s, maxb=33656KB/s, mint=95736msec, maxt=95736msec WRITE: io=1023.2MB, aggrb=10943KB/s, minb=11206KB/s, maxb=11206KB/s, mint=95736msec, maxt=95736msecTakže nejedná se o test výkonu těch qcow2, to nemám. Navíc test výkonu toho nfs je přes agregovanou linku, resp. NetApp QoSí na 2,5Gbit.
Ze začátku jsem používal web virt manager, který podporoval snapshoty a další věci jen s qcow, na což jsem přišel až později.No všem těmhle věcem se ze zásady vyhýbám a snažím se to dělat na tak nízké vrstvě, na které jsem ještě schopen. Protože všechna takhle klikátka jsou hrozně fajn a to přesně to chvíle, než člověk narazí na něco, co to neumí a nebo to chvíle, kdy se něco pokazí. Takže potom u některých adminů nastavá fáze "toto udělat přes klikátko a toto už ručně" a v případě pokažení se to většinou pokazí tak důkladně, že už to nejde opravit. A abych okamžitě porušil to, co jsem teď tvrdil, tak používám virsh na cli.
Tiskni
Sdílej: