Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Ř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: