Dotaz: kopie přes linky

[hufhendr]

Dobrý den,

chtěl bych se zeptat, zda někdo neřešil kopie adresářové struktury přes pevné linky?

Mám představu, adresář1 včetně podadresářů by se nakopíroval na adresář2 se stejnými podadresáři a jednotlivé soubory by se "překopírovaly" už jen jako pevné linky v rámci jednoho filesystému.

Ve finále by byly dva různé adresáře se stejným obsahem a na disku by to zabíralo místo jen jednou.

Předem děkuji za nasměrování na nástroj nebo script.

---

---

Odpovědi

[NN]

Tak je to mozne, skript na par radek, ale otazka je k cemu je to cele dobre?

[hufhendr]

Na SSD disku není dost místa a jeden datově objemný projekt končí a další plynule navazuje. Některé soubory budou časem v nové struktuře mizet a ve staré mají zůstat zachované na původním místě. Naopak nové soubory mají být jen v nové struktuře. Při záloze např. tarem to ovšem bude jen tak veliké, kolik to doopravdy bere místa.

Máte takový script?

[Michal Kubeček]

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.

[xkucf03]

Nebo spíš souborový systém jako Btrfs.

(u verzovacího systému máš ta data minimálně dvakrát)

[Michal Kubeček]

To sice ano, ale pokud podle popisu se u těch projektů očekává nějaký vývoj a pak je rozhodně žádoucí mít přinejmenším přehled, co se v nich kdy měnilo, a možnost vyvolat si kteroukoli předchozí verzi.

[Andrej]

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.

[hufhendr]

Děkuji moc i za další podnětnou diskusi. Použil jsem cp -lr a jsem naprosto spokojený. Výsledkem jsou 2 naprosto totožné adresáře a místo na disku to zabírá opravdu jen jednou. Pokud se změny v některých souborech přenesou do adresáře původního, nebude mi to nijak vadit - jde mi spíše o hierarchii v adresářová struktuře, která se bude nově bezpochyby měnit a symbolické linky by se potrhaly.

Zdá se, že i cloudový klient to nějak pochopil a nový adresář "nahrál" bez navýšení obsazeného prostoru. Teď zrovna probíhá synchronizace na druhý počítač, snad nespadne do nekonečné smyčky.

[Josef Kufner]

Ano, změny se propíšou, neboť to je jeden a ten samý soubor, který je na filesystému na dvou místech. Je to velmi nebezpečný způsob používání hardlinků a vymstí se ti to.

Cloudový klient to pochopí snadno. Stačí mít nějakou deduplikaci, která zjistí, že soubory jsou stejné a zachová se podle toho. Tuhle deduplikaci však můžeš mít i u sebe. Možností je povícero. Rozhodně by to bylo spolehlivější než to řešit hardlinkama.

[hufhendr]

Už vidím, že to trochu drhne. V novém adresáři jsem přesunul pár souborů jinam a na zdrojovém počítači to zafungovalo dobře, u souborů mám stále 2 inode. Na druhém počítači ale Copy klient soubory z původního adresáře odmazal a na nové místo nahrál nově.

Na tu deduplikaci musím přejít z EXT4 na BTRFS? Není to nebezpečné?

[Josef Kufner]

Deduplikace může být buď na aplikační úrovni, nebo na úrovni filesystému, nebo na úrovni blokového zařízení. Obojí má své pro i proti. Záleží na tom, co se ti bude hodit víc. Git dělá deduplikaci na aplikační úrovni, kdy spočítá hash každého souboru a uloží si ho pod tím hashem. BTRFS má copy-on-write, kdy zkopírování souboru je něco jako vytvoření hardlinku, ale při změně se udělá kopie. Pak je ještě deduplikace jako taková, kdy se uloží soubor a nějaký démon pak (např. v noci) hledá kopie a maže je (nebo spíš slučuje a pak se použije to copy-on-write), případně se ta kontrola udělá rovnou při ukládání (což zdržuje).

Vlastní zkušenost s tím však moc nemám. Používám jen hardlinky vytvářené rsnapshotem při zálohování, neboť zálohy jsou read-only a nehrozí tedy, že bych si přepsal něco, co jsem nechtěl.

[Michal Kubeček]

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.

[Josef Kufner]

To jo, ale zrovna v tomto případě se to hodí. Jen je poněkud nepraktické si hlídat, který editor to dělá a který ne. A při které operaci nepřijde o stará data.

[rastos]

cpio:

'-l, --link'
Link files instead of copying them, when possible.

[Andrej]

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.

[Michal Kubeček]

Asi by bylo dobré hned na začátku upozornit, že toto řešení má jednu zásadní nevýhodu: funguje jen s jedním konkrétním filesystémem - a nikde není psáno, že tam tazatel má právě ten.

[dustin]

Tak. Kopie souborů hardlinky tu již zazněla, není potřeba žádné skripty: cp -rl

[Andrej]

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.

[mhepp]

Ano, ale je to tak. V roce 2015 je caste, ze pouzity FS neumi snapshoty a tak.

Ono je to tim, ze BTRFS je casto oznaceno jako vyvojove a nese si to jako stigma a ZFS neni nativni soucast Linuxu. Co zvoli potom zmatena lama?

Nastesti, ext4 se da konvertovat na BTRFS bez ztraty dat...

[Michal Kubeček]

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.

[Andrej]

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.

[xkucf03]

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í.

[xkucf03]

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).

[dustin]

Co kolem sebe vidím a čtu, tak mi spíše přijde nepravděpodobné, že by někdo v ostrém nasazení jeden z těch fs měl. Navíc je potřeba si uvědomit, že s upgradem HW se často disky nechávají původní, nebo se v serverech se SW raidem vyměňují po jednom, sync + finálním resizem partišny a filesystému, až jsou vyměněné všechny. Změna filesystému je pořádný zásah.

Určitě je dobré btrfs dělat osvětu, ale samozřejmostí se stane až za dost dlouho...

[Andrej]

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.

[Jendа]

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

[dustin]

Hm, zrovna tohle mě moc nepřesvědčilo http://www.phoronix.com/scan.php?page=news_item&px=Facebook-More-Btrfs . V srpnu 2015 to plánovali "během několika měsíců nasadit do ostrého provozu". Mají na btrfs vlastní vývojáře a letos již odstranili řadu chyb. Letos, ne před lety.

Ale jsem za ně rád, až to za pár let vychytají, rád na btrfs přejdu.

[lertimir]

A jak to má s nasazením Oracle Linux? ten si myslím jede primárně na btrfs.

[paf1]

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