Národní identitní autorita, tedy NIA ID, MeG a eOP jsou nedostupné. Na nápravě se pracuje [𝕏].
Americký výrobce čipů Nvidia se stal první firmou na světě, jejíž tržní hodnota dosáhla pěti bilionů USD (104,5 bilionu Kč). Nvidia stojí v čele světového trhu s čipy pro umělou inteligenci (AI) a výrazně těží z prudkého růstu zájmu o tuto technologii. Nvidia již byla první firmou, která překonala hranici čtyř bilionů USD, a to letos v červenci.
Po Canonicalu a SUSE oznámil také Red Hat, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie).
TrueNAS (Wikipedie), tj. open source storage platforma postavená na Linuxu, byl vydán ve verzi 25.10 Goldeye. Přináší NVMe over Fabric (NVMe-oF) nebo OpenZFS 2.3.4.
Byla vydána OpenIndiana 2025.10. Unixový operační systém OpenIndiana (Wikipedie) vychází z OpenSolarisu (Wikipedie).
České základní a střední školy čelí alarmujícímu stavu kybernetické bezpečnosti. Až 89 % identifikovaných zranitelností v IT infrastruktuře vzdělávacích institucí dosahuje kritické úrovně, což znamená, že útočníci mohou vzdáleně převzít kontrolu nad klíčovými systémy. Školy navíc často provozují zastaralé technologie, i roky nechávají zařízení bez potřebných aktualizací softwaru a používají k nim pouze výchozí, všeobecně známá
… více »Během tradiční ceremonie k oslavě Dne vzniku samostatného československého státu (28. října) byl vyznamenán medailí Za zásluhy (o stát v oblasti hospodářské) vývojář 3D tiskáren Josef Průša. Letos byly uděleny pouze dvě medaile Za zásluhy o stát v oblasti hospodářské, druhou dostal informatik a manažer Ondřej Felix, který se zabývá digitalizací státní správy.
Tor Browser, tj. fork webového prohlížeče Mozilla Firefox s integrovaným klientem sítě Tor přednastavený tak, aby přes tuto síť bezpečně komunikoval, byl vydán ve verzi 15.0. Postaven je na Firefoxu ESR 140.
Bylo oznámeno (cs) vydání Fedora Linuxu 43. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách Fedora Magazinu: Fedora Workstation, Fedora KDE Plasma Desktop, Fedora Silverblue a Fedora Atomic Desktops.
Elon Musk oznámil (𝕏) spuštění internetové encyklopedie Grokipedia (Wikipedia). Zatím ve verzi 0.1. Verze 1.0 prý bude 10x lepší, ale i ve verzi 0.1 je podle Elona Muska již lepší než Wikipedia.
Řešení dotazu:
Jak se dá udělat dd ze tří disků na jeden?
Je to jen o místě. Rozhodně to není vhodný způsob na průběžné zálohy, ale na přesypání Btrfs jak leží a běží. Alespoň tak jsem pochopil ten dotaz.
dd obsah všech disků, co do toho FS patří. Ideálně na nějaký jiný diskový prostor, než kde pak bude to Btrfs.A nemusí to být nutně soubory. To dd se dá sypat na logické disky vytvořené přes LVM. Důležité je vědět co se má kopírovat.
Nicméně dotaz směřoval k tomu, jak relativně jednoduše překopírovat obsah jednoho btrfs souborového systému (s daty) na druhý ...
Přečti si ten dotaz ještě jednou. O jednoduchosti tam nic nepsal. To bych mu totiž doporučil úplně jiný postup.
... and then try to mount either the original or the snapshot while both are visible to the same kernel.
Tak předpokládám, že je snad bylo dostatečně jasné, že se to zkopírované Btrfs nemountuje na stejné mašině.
?
Promiň, ale tenhle text nemá ani hlavu ani patu. Btrfs si nic nevybírá. Prioritu určuje devid. A ten se při zkopírování nezmění. Navíc Btrfs v raid1 znamená, že jsou zrcadlené extenty, takže je úplně jedno který by se vzal jako prioritní, protože musí být oba stejné. To není MD raid.
Problém by mohl nastat podle mne jen v tom případě, že by s tím Btrfs laboroval přes loop zařízení na stejném stroji, kde je ten zkopírovaný FS.
Jinak jak už jsem uvedl. Osobně bych volil jiný postup. Živý subvolume ORIG na stroji A bych snapshotoval do ORIG-snapshot. A obsah ORIG-snapshot bych pak nechal rsyncem přesypat po síti na stroj B do subvolume COPY, které bych po skončení přenosu následně snapshotoval na COPY-YYYY-MM-DD.
ORIG-snapshot bych nechal do vytvoření nového snapshotu jako zálohu. V případě nabourání původního živého subvolume je pak rychlejší obnova než tahání dat ze zálohy. A když by to exlo celé, tak se může buď použít stroj B, nebo jeho úložiště.
Existuje tohle, ale vypadá to, že se současnými btrfs-progs už to nefunguje, přinejmenším ne bez tohoto pull requestu. (Který je hodně dlouho nevyřízený, projekt vypadá opuštěný atd.)
(Osobně bych to použil spíš jako zdroj informací, jak získat správné pořadí snapshotů, než cokoliv jiného…)
Jinak mám dojem, že ID snapshotů i jejich generace jsou (pro snapshoty od téhož subvolume) rostoucí:
ID 7670 gen 2464653 top level 5692 path arch_backup/-home-andrej.homedir/2022-03-13 03:29:12 1647138552424922035 ID 7922 gen 2465820 top level 5692 path arch_backup/-home-andrej.homedir/2022-06-01 04:30:18 1654050618104307446 ID 8042 gen 2467422 top level 5692 path arch_backup/-home-andrej.homedir/2022-07-10 04:31:05 1657420265191933125 ID 8168 gen 2470613 top level 5692 path arch_backup/-home-andrej.homedir/2022-08-22 03:21:39 1661131299222195966 ID 8232 gen 2471859 top level 5692 path arch_backup/-home-andrej.homedir/2022-09-10 03:01:23 1662771683812132780 ID 8260 gen 2471987 top level 5692 path arch_backup/-home-andrej.homedir/2022-09-19 03:46:38 1663551998097155372 ID 8278 gen 2472074 top level 5692 path arch_backup/-home-andrej.homedir/2022-09-25 03:07:56 1664068076400995511 ID 8284 gen 2472133 top level 5692 path arch_backup/-home-andrej.homedir/2022-09-28 03:45:20 1664329520797886672 ID 8298 gen 2472136 top level 5692 path arch_backup/-home-andrej.homedir/2022-10-01 03:36:28 1664588188068882102
Tam↑↑↑ bude ovšem nutné se přesvědčit, které z těch čísel je rostoucí jenom náhodou a u kterého to opravdu garantuje dokumentace.
Já si například myslím, že ZFS (bohužel) zabíjí jeho licence, konkrétně tedy nemožnost začlenění do kernelu.
V posledních letech jsou sice DKMS moduly pro ZFS celkem použitelné, ale i tak se mi tu a tam stane, že se s novou verzí kernelu nepřeloží a je třeba čekat pár dnů (až pár týdnů), než to někdo opraví. Kdybych měl ZFS jako hlavní (nebo jinak důležitý) filesystém, tohle by mi celkem kazilo náladu.
Na mých většinou denně (a nejdéle týdně) aktualizovaných strojích podpora pro Btrfs vždy prostě je, out-of-the-box, i na custom kernelech, a nemusím se při každé aktualizaci (která je v ideálním případě zcela automatická) zabývat otázkou, zda se tentokrát ZFS přeloží nebo ne.
Je ovšem jeden případ, kde ZFS nemá žádnou konkurenci ani alternativu: FreeBSD. Jasně, na FreeBSD Btrfs nemám a tam ZFS zkrátka rulezzz.
Záleží na tom, jestli člověk opravdu potřebuje online deduplikaci na ZFS.
Na Btrfs není a mně osobně nikdy nechyběla; hodí se pro jiná nasazení a jiná data, než mám já.
No a bez deduplikace žádný zásadní problém s pamětí u ZFS nevidím. V požadavcích se píše cosi o 2 GB RAM.
Tiskni
Sdílej: