Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Řešení dotazu:
Nepotřebujete skript, stačí použít "cp -lr
".
Spíš je otázka, jestli by nebylo vhodnější používat nějaký systém správy verzí (třeba git), zvlášť jestli jde o textové soubory.
Nebo spíš souborový systém jako Btrfs.
(u verzovacího systému máš ta data minimálně dvakrát)
Nebo spíš souborový systém jako Btrfs.
Přesně tak. Další možnosí je ZFS. cp --reflink
bude na ZFS fungovat přesně stejně jako na Btrfs. Jen to snapshotování bude mít na ZFS o jeden krok navíc, protože napřed se musí z existujícího filesystému vytvořit read only snapshot a z toho snapshotu se pak teprve dá instanciovat nový zapisovatelný filesystém. (Filesystémy na ZFS, obdoba Btrfs subvolumes, jsou navíc uspořádané hierarchicky a zcela odděleně od adresářové struktury, částečně kvůli oprávněním nakládat s nimi atd. atp.) Ale v základním principu je to velice podobné. No a pokud ta kopie nepotřebuje být zapisovatelná, pak je postup vlastně stejný jako na Btrfs, jen s jinými utilitami.
A ještě další možnost je opět použít ZFS, ale prostě to úplně prasácky zkopírovat nejobyčejnějším možným cp
— a mít zapnutou deduplikaci. Ono se to po čase deduplikuje. Ale to samozřejmě nevyřeší problém s akutním nedostatkem místa, zatímco cp --reflink
(nebo snapshoty) už ano.
Ano, změny se propíšou
Zdaleka ne všechny. Je bohužel spousta programů - včetně editorů :-( - které soubory nepřepisují, ale nahrazují novým.
cpio:
'-l, --link'Skript je takhle jednoduchý:
cp -a --reflink adresář0 adresář1
Tohle ovšem nedělá pevné linky. Ve srovnání s pevnými linky to má zásadní výhodu: změna souborů v jednom z adresářů, ať už chtěná nebo nechtěná, nijak neovlivní ten druhý adresář. Ale dokud k té změně nedojde, data zabírají místo pouze jednou. (O metadatech nelze říct totéž, ale metadat je o několik řádů méně.) V případě změn se pochopitelně duplikuje blok po bloku (víceméně), nikoliv celé soubory.
Pak existuje mnohem jednodušší a efektivnější postup bez explicitního „kopírování“, samozřejmě opět s výhodou zachování původního stavu každé z kopií v případě změny té druhé kopie. Jenom se s tím musí předem počítat:
btrfs subvolume create adresář0 mv /odněkud/* adresář0
A pak už je to triviální úkon:
btrfs subvolume snapshot adresář0 ./adresář1
Pokud by snad někdo striktně trval na hard lincích (a chtěl by riskovat, že poškození jedné kopie poškodí také tu druhou, případně kdyby takové chování bylo požadavkem), existuje option --link-dest
pro rsync
, který lze (mimo jiné) použít k dosažení tohoto cíle. Výše uvedená řešení jsou ovšem nesrovnatelně jednodušší a ještě s bonusem v podobě copy on write.
cp --reflink
funguje přinejmenším se dvěma filesystémy, ZFS a Btrfs.
Připadá mi nepravděpodobné, že by v roce 2015 někdo aspoň jeden z těchto filesystémů neměl, takže jsem si dovolil existenci základních funkcí jako jsou snapshoty prostě pokládat za samozřejmou.
funguje přinejmenším se dvěma filesystémy, ZFS a Btrfs
ZFS je AFAIK v Linuxu podporovaný jen pokud buď ignorujete licenci nebo použijete FUSE driver. Ani jedno není něco, co bych si dovolil někomu doporučit pro běžné používání.
Připadá mi nepravděpodobné, že by v roce 2015 někdo aspoň jeden z těchto filesystémů neměl
Váš předpoklad je značně vzdálen realitě. Aktuální verze některých distribucí sice btrfs vnucují jako default, ale i tak je dost těch, kdo si buď tento default při instalaci změní nebo příslušný filesystém vytvářeli už dříve (což bude nejspíš i případ tazatele).
…takže jsem si dovolil existenci základních funkcí jako jsou snapshoty prostě pokládat za samozřejmou.
To je velmi odvážný předpoklad. Ne, snapshoty ani zdaleka nejsou základní funkcí a už vůbec ne něčím, co by se automaticky dalo předpokládat, aniž by bylo potřeba se o tom vůbec zmínit.
ZFS ve FUSE je passé, stará záležitost, starý FUD, dá se říct. Kernelový ZFS nevyžaduje žádné ignorování licence. Prostě se nedistribuuje s kernelem, ale zvlášť. Tím je licenci učiněno zadost. Uživatel si pak zkompiluje spl, zfs a pár dalších potřebných modulů. Nebo si je doinstaluje z nějaké repository — implementace není podstatná. Protože licence kernelu i ZFS jakékoliv použití nemodifikovaného softwaru (bez snahy o další distribuci) beze zbytku umožňují, žádné obcházení licence v tom není.
Ano, pravda je, že některé předpoklady jsou poměrně odvážné, ale připadá mi smutné, když vidím už asi padesátý dotaz směřující k tomu, jak v nějakém poměrně zastaralém filesystému zajistit vlastnost, kterou ZFS a Btrfs umí nativně a bez námahy. Sám mám na svých systémech Btrfs od roku 2010 a návrat do dob bez checksumů, konzistentních snapshotů a smysluplného RAIDu, odolného proti silent data corruption, si nějak neumím představit.
Uživatel si pak zkompiluje spl, zfs a pár dalších potřebných modulů. Nebo si je doinstaluje z nějaké repository — implementace není podstatná. Protože licence kernelu i ZFS jakékoliv použití nemodifikovaného softwaru (bez snahy o další distribuci) beze zbytku umožňují, žádné obcházení licence v tom není.
Což je použitelné jen pro domácí hraní si nebo nějaké bastly případně speciální případy, kdy má firma vlastní vývojáře a jaderné hackery, ale je to bohužel nepoužitelné pro komerční dodávky, kde se jedna firma specializuje na IT a druhá na něco jiného a to IT jen používá (protože tam by docházelo k distribuci). Škoda té CDDL licence… Spíš bych tedy šel do Btrfs a pracoval na jeho dalším vylepšování.
a smysluplného RAIDu
K dokonalosti ještě chybí smysluplné šifrování, protože bez něj musíš použít buď mdraid (a přijdeš o výhody RAIDu v Btrfs) nebo budeš muset všechna zapisovaná data šifrovat dvakrát (dva samostatně šifrované oddíly/disky a nad nimi Btrfs RAID).
Co je to ostré nasazení? ZFS je v ostrém / produkčním / <sem lze doasdit téměř libovolný buzzword> nasazení asi tak od roku 2008 a nezdá se, že by byl jakkoliv problematický. (Ano, pravda, pro ZFS na Linuxu to s rozšířeností není až tak valné a není až tolik OpenIndianových nebo FreeBSD nasazení.)
Btrfs používá například Facebook. Na wiki Btrfs se dá najít seznam „ostrých“ nasazení (nepříliš udržovaný a nepříliš aktuální, ale přece). Takže nasazení Btrfs není pravděpodobné, nýbrž jisté.
To s RAIDem je samozřejmě pravda. Přechod od hardwarového / mdadm / dmraid systému na RAIDZ nebo na Btrfs RAID je prostě radikální řez, který se nedá provést disk po disku… No, tak to prostě je.
Přechod od hardwarového / mdadm / dmraid systému na RAIDZ nebo na Btrfs RAID je prostě radikální řez, který se nedá provést disk po disku…Nebylo třeba rozumné recovery RAID5 přidáno teprve nedávno?
a nezdá se, že by byl jakkoliv problematickýMně všech čtyřech strojích, kde ho mám, způsobuje nevysvětlitelné někdy až minutové zátuhy. Mount při tom podle iotopu čte 3 MB/s, jestli to visí na seekování, to bohužel neumím zjistit. Jsou to kernely 3.19 - 4.1.
# sync; date; umount /mnt/backup; date; sync; date; mount /mnt/backup; date Thu Dec 24 04:49:24 CET 2015 Thu Dec 24 04:49:25 CET 2015 Thu Dec 24 04:49:25 CET 2015 Thu Dec 24 04:49:37 CET 2015
Jeste jeden hint - pomerne dobre to resi aplikace "backintime" - http://backintime.le-web.org/
Primarne urcena pro zalohovani, ale i na toto lze dobre pouzit ( princip hardlinku )
Paf1
Tiskni Sdílej: