Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
Zdravim opet pisi radeji do blogu, nez abych spamoval diskuzi. Zamerem blogspotu je rozvinout nejakou diskuzi na dane tema. Nuze pojdme do toho.
Hodlam z one-disc desktopu prejit na RAID1 desktop. A jelikoz jsem liny a mam zde docela hodne dat o ktere bych jen nerad prisel rozhoduji se jak na migraci pujdu. Jak jsem jiz napsal do nadpisu premyslim nad RAID1 nebo LVM (mirroring).
Otazkou zustava co je jednodussi a proveditelne bez toho abych musel cely disk zalhovat a instalovat cely system znovu. U RAIDU mam prakticky dve moznosti, pouzit bud integrovany radic na desce o nemz ale silne pochybuji navic se obavam ze toto reseni se bez formatu neobejde. Druhou moznosti je RAID softwarovy, ktery by si mel teoreticky s pridanim noveho disku poradit hrave. Pokud se nemilim melo by stacit disk rodelit na stejne partisny a pak jen syncnout pres mdadm
. Predpokladam ze se syncne i LVM ktery na disku je.
Timto se dostavam k LVM. Napadlo me ze dalsi moznosti je vyuzit stavajici LVM ktere je naprosto funkcni. Tato moznost, tedy mirroring disku je podle meho nazoru asi nejjednodussi reseni. Proste a jednoduse pridam do existujici lvgroup dalsi disk, rodelim a nastavim mirroring.
Ma nekdo zkusenosti s nabizenymi resenimi, pripadne jinymi moznostmi? Doporucite spise RAID nebo LVM? Jak je na tom vykon LVM mirroringu v porovnani RAID1. Ocekavam totiz i navyseni rychlosti cteni z disku.
Dekuji vsem za namety.
Tiskni
Sdílej:
Raději doplňím, jak fake raid funguje:
Firmware diskového řadiče má zadrátovanou (obvykle proprietární) podobu metadat pro RAID, která jsou uložena na discích tvořících RAID. Kód firmwaru je zavěšený na přerušení používaném pro přístup na bloková zařízení skrze služby BIOSu a po dobu bootu (načtení zavaděče a obrazu jádra) tak skutečně plní funkci RAID řadiče.
Po nabootování operačního systému musí operační systém rozluštit ony proprietární datové struktury a na jejich základě sestavit softwarový RAID identický s tím, jak si jej představuje BIOS. Pak se už BIOS nepoužívá a vše si dělá OS sám.
V Linuxu to řeší balík dmraid, což jsou programy pro uživatelský prostor, které některé formáty metadat znají (seznam lze najít v dokumentaci a na webu projektu). Prohledají disky, a když metadata najdou, tak přes jaderný device mapper sestaví softwarový RAID. Takže to je v podstatě obdoba LVM, jen se používají jiné struktury metadat.
Z tohoto hlediska fake RAID přináší dvě výhody: máte hardwarově asistovaný přístup k poli při bootu (nemusíte řešit, zda si zavaděč rozumí s RAIDem) a rovněž můžete používat stejný RAID při dualbootu ve Windows. Nevýhodou je, že máte bootování vázané na konkrétní model řadiče disků. Stabilita a rychlost je totožná s LVM.
Pokud použijete RAID, tak asi určitě SW. Kromě toho, že řadič na disku bude takový ten fake RAID máte u SW poměrně bezbolestné řešení toho, když odejde právě třeba deska (i když si teď nejsem jistý jestli se v Linuxu u těch integrovaných řadičů nepoužije stejný formát jako u SW RAIDu). Výkonnostně je SW RAID jisté zpomalení, podle giannis.stoilis.gr/md-benchmarks.txt z roku 2005 je sice rychlejší než ty integrované bazmeky, ale www.linux.com/feature/140734 ukazuje, že i v RAID10 je v o něco pomalejší než skutečny HW RAID (do kterého ale, předpokládám, investovat nechcete, nemluvě o řadě negativních zkušeností, které s HW RAID mnozí lidé mají).
Co se týká LVM mirroringu, tak je potřeba upozornit na to, že pro reálné použití potřebujete na Linuxu 3 disky (viz manuálovou stránku např. na www.linuxcertif.com/man/8/lvcreate/ a parametr mirrorlog).
Co se týká LVM mirroringu, tak je potřeba upozornit na to, že pro reálné použití potřebujete na Linuxu 3 disky (viz manuálovou stránku např. na www.linuxcertif.com/man/8/lvcreate/ a parametr mirrorlog).
Dekuji toho jsem si nevsimnul.
no tak zrovna corelog asi nenni nejlepsi volba, protoze pri kazdem rebootu dojde k resyncu celeho raidu. jednodussi je proste udelat raid o malinko mensi a log hodit na jeden z disku.
kazdem rebootu dojde k resyncu celeho raidu
Tak, tak. Přesně z toho důvodu jsem psal o reálném využití. To použití samostatné partition na jednom z disků není špatný nápad, ale nejsem si jistý, jak velká může být potřeba. Máte s tím nějaké zkušenosti?
Osobně mě tato vlastnost mirrou u linuxového LVM dost štve, protože flexibilita LVM + mirror oproti LVM nad RAID je někde úplně jinde.
ralna:~# lvdisplay -m vgtest/lvol0 --- Logical volume --- LV Name /dev/vgtest/lvol0 VG Name vgtest LV UUID l9VvAr-6IFj-9ZdA-Q2yb-77vt-F3jG-CuU8xI LV Write Access read/write LV Status available # open 2 LV Size 2,00 GB Current LE 512 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:10 --- Segments --- Logical extent 0 to 511: Type mirror Mirrors 2 Mirror size 512 Mirror region size 512,00 KB Mirror original: Logical volume lvol0_mimage_0 Logical extents 0 to 511 Mirror destinations: Logical volume lvol0_mimage_1 Logical extents 0 to 511a toto je LV vytvorena s disk logem:
ralna:~# lvdisplay -m vgtest/lvol1 --- Logical volume --- LV Name /dev/vgtest/lvol1 VG Name vgtest LV UUID e1UdqI-XCsV-0lKs-0fJx-PUPi-h3Zf-QxMqwV LV Write Access read/write LV Status available # open 0 LV Size 1,00 GB Current LE 256 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:14 --- Segments --- Logical extent 0 to 255: Type mirror Mirrors 2 Mirror size 256 Mirror log volume lvol1_mlog Mirror region size 512,00 KB Mirror original: Logical volume lvol1_mimage_0 Logical extents 0 to 255 Mirror destinations: Logical volume lvol1_mimage_1 Logical extents 0 to 255cela VG:
ralna:~# vgdisplay -v vgtest Using volume group(s) on command line Finding volume group "vgtest" --- Volume group --- VG Name vgtest System ID Format lvm2 Metadata Areas 3 Metadata Sequence No 7 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 1 Max PV 0 Cur PV 3 Act PV 3 VG Size 8,00 GB PE Size 4,00 MB Total PE 2049 Alloc PE / Size 1537 / 6,00 GB Free PE / Size 512 / 2,00 GB VG UUID SUNKZR-5B74-KgjN-99HO-6Ahw-9gCW-XOfJ8V --- Logical volume --- LV Name /dev/vgtest/lvol0 VG Name vgtest LV UUID l9VvAr-6IFj-9ZdA-Q2yb-77vt-F3jG-CuU8xI LV Write Access read/write LV Status available # open 2 LV Size 2,00 GB Current LE 512 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:10 --- Logical volume --- LV Name /dev/vgtest/lvol1 VG Name vgtest LV UUID e1UdqI-XCsV-0lKs-0fJx-PUPi-h3Zf-QxMqwV LV Write Access read/write LV Status available # open 0 LV Size 1,00 GB Current LE 256 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:14 --- Logical volume --- LV Name /dev/vgtest/lvol0_mimage_0 VG Name vgtest LV UUID Mnb4Mh-y4ws-Hq4r-Nkc0-EhGt-fLTA-YjZ2vR LV Write Access read/write LV Status available # open 1 LV Size 2,00 GB Current LE 512 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:8 --- Logical volume --- LV Name /dev/vgtest/lvol0_mimage_1 VG Name vgtest LV UUID Q6FAYg-BGEo-pMO4-LUC2-SHeX-WmBZ-kR4hz1 LV Write Access read/write LV Status available # open 1 LV Size 2,00 GB Current LE 512 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:9 --- Logical volume --- LV Name /dev/vgtest/lvol1_mlog VG Name vgtest LV UUID 05G0y5-aPVa-O4LA-t5Pl-Aui0-H1LV-dF1M6z LV Write Access read/write LV Status available # open 1 LV Size 4,00 MB Current LE 1 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:11 --- Logical volume --- LV Name /dev/vgtest/lvol1_mimage_0 VG Name vgtest LV UUID qGjqYX-bH0C-QCog-vSVg-W0JE-MN8S-YYGPa9 LV Write Access read/write LV Status available # open 1 LV Size 1,00 GB Current LE 256 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:12 --- Logical volume --- LV Name /dev/vgtest/lvol1_mimage_1 VG Name vgtest LV UUID yj2mB3-ufKx-LIZq-XRge-QvSx-mjfy-cfQ5mu LV Write Access read/write LV Status available # open 1 LV Size 1,00 GB Current LE 256 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:13 --- Physical volumes --- PV Name /dev/loop0 PV UUID LoK0EL-TE50-YeT0-FWJq-lm4K-QlUv-m4J0sX PV Status allocatable Total PE / Free PE 976 / 208 PV Name /dev/loop1 PV UUID h07NlG-CzVM-LFpC-kO1W-8AqD-gzN5-uySWsC PV Status allocatable Total PE / Free PE 976 / 208 PV Name /dev/loop2 PV UUID 0qjULf-ispG-sMvD-8gy4-J1tD-f1tv-W9oD9v PV Status allocatable Total PE / Free PE 97 / 96
mdadm
uděláš sice také, ale musíš si to rozmyslet dopředu. LVM ti umožní si s tím libovolně hrát kdykoliv za běhu. Osobně to mám takto: Spoustu jednoduchých oddílů s daty, pak stripe set pro /home
a databáze a konečně mirror pro /backup
, ze kterého se to pak kopíruje na jiný stroj. Zálohovací oddíl mám zrcadlený proto, že v případě výpadku jednoho HDD v tom stroji to stačí jednoduše zkopírovat z toho /backup (vytáhnout to z druhého stroje je zdlouhavější, tam to není dělané na rychlý přístup k jednotlivým souborům).
Mirror není záloha! Takže pokud tam máš "docela hodne dat o ktere bys jen nerad prisel", tak krom mirroru ještě musíš vyřešit zálohu.
Mirror není záloha! Takže pokud tam máš "docela hodne dat o ktere bys jen nerad prisel", tak krom mirroru ještě musíš vyřešit zálohu.
Toho jsem si vedom. Zaloha je vyresena, ale jde mi o to ze je jednodussi udelat sync nez obnovovat ze zalohy. Samozrejme jen v pripade kdyz clovek nema takvou smulu a neumrou mu oba disky najednou, nebo ve velmi kratkem casovem rozestupu.
Syncuju jednou denně rsnapshotem na "backup" oddíl. Rsnaphot dělá hardlinky, takže mám k disposici adresářovou strukturu určený počet dnů nazpět a přitom to zabírá jen o málo víc než zálohovaná data (vlastně jen o změny). A protože je to vlastně rsync pracovního adresáře (a ne nějaký druh komprimovaného archivu), tak lze smazaný nebo omylem změnený soubor rychle obnovit.
Pravou zálohu dělám prostým zkopírováním tohoto adresáře jinam.
Je to uz opravdu dlouho, kdy jsem tento problem resil. Na nejake strance od tvurcu LVM jsem nasel ze nedoporucuji vyuzivat LVM mirror, ze mdadm je rockstable. Takto to taky vyuzivam, Mdadm a pripadne nad nim LVM, kdyz pozadujete jeho sluzby.
init
do takové úrovně běhu, ve které neběží služby (typicky 1), znovu rsyncovat, upravit fstab a grub a rebootnout.
Proč se vlastně namáhám s psaním postupu... tady je článek Michala Čihaře
Delal jsem to uz vickat a za chodu - pri kazdem prevzeti serveru do me pece, nebo kdyz nejaky puvodne doplnkovy stroj se najednou stal dulezitym (to bylo v nedavnych dobach, kdy jsem nepouzival virtualizace tak mohutne).
Tedy vzdy jsem mel LVM a vic nez jeden disk.
Zvolil jsem soft raid, protoze pro mne je vyborny ve vsech smerech a predevsim tak ziskavam jednotne rozhrani - tedy nemeni se nic kdyz poridim jiny hw raid a nemusim se bat, ze se ho budu muset ucit kdyz neco selze - proto sw raid i kdyby mel nejake vady.
Vytvoril jsem raid zarizeni, keremu aktualne chybi jeden z disku (missing) a vytvoril jsem z nej pvolume (pvcreate), nasledne jsem jej pridal do vg (vgextend) a zacal jsem se zbavovat puvodniho disku (removing an old disk v LVM HOWTO - tedy pvmove).
Pak jsem puvodni partititon z puvodniho dsku odstranil a vytvoril jsem na nem taky partition typu FD a pridal do stavajiciho pole.
Vse bez restartu a na dalku na pateri a jeste k tomu vsem aplikacim a userum "pod prdeli".
LVM pouzivam zasadne vsude i kdyz jakoby "neni potreba" a to ze dvou duvodu:
1. nikdy nechci byt omezovan prvotnim rozhodnutim o velikosti oblasti
2. pouzivam zalohovani pomoci snapshotu a to je velika mazarna, kdyz to funguje obecne a naprosto spolehlive