Vlákno názorů k článku
XFS se připravuje na COW a deduplikaci
od dustin - XFS používáme skoro 15 let, některé filesystémy budou...
-
FíkZlatý podporovatelu XFS se za tu dobu možná změnily výchozí hodnoty v mkfs.xfs, možná by bylo přeformátování na místě? případně naformátovat zkušebně volné místo (prázdný soubor) a podívat se pomocí xfs_info jaké má parametry nový a starý fs
a kopie bych radši dělal tar + mkfs.xfs než dd
-
dustin (neregistrovaný)
Každé kopírování znamená downtime serveru. lineární dd je několikanásobně rychlejší, než seekovací tar či xfsdump.
Navíc na největším fs máme storage pro backuppc, které pro aplikační deduplikaci používá hardlinky. Za ty roky jich na těch 9TB vyrobil hodně set miliónů. To se blbě xfsdumpuje za rozumný čas. Zato záloha na externí pole synchronizací sw raidu1 se sledováním změn writeintent bitmapou trvá na normálních SATA 7k2 discích hodinu. Tohle pole zvětšujeme postupným nahrazováním disků za větší a nasledným resizem filesystému, nic se nekopíruje. Ostatní pole jsou na raid10, tam bohužel linux zatím resize neumí, takže dd na větší + xfs_growfs.
Jo, snapshoty se budou hodit.
-
Jenda (neregistrovaný)
> Každé kopírování znamená downtime serveru. lineární dd je několikanásobně rychlejší, než seekovací tar či xfsdump.
A to nemůžeš mít ty storage online současně? Nejdřív to zkopíruješ, což může trvat libovolně dlouho, a pak to vypneš a pustíš rsync, který přenese jenom změny, což je rychlé.
S těma hardlinkama je to pakárna a je to hlavní důvod, proč jsem zálohy přemigroval na btrfs, protože tam snapshoty na rozdíl od vytváření hardlinků nemají takový overhead.
-
dustin (neregistrovaný)
>A to nemůžeš mít ty storage online současně? Nejdřív to zkopíruješ, což může trvat libovolně dlouho, a pak to vypneš a pustíš rsync, který přenese jenom změny, což je rychlé.
Jasně, i tohle někdy dělám, když není potřeba držet hardlinky. Dřív se ale do pole někdy nevešel dvojnásobek disků, takže byl nutný provoz částečně degradovaného (část disků z pole A se použilo v poli B), tudíž bylo potřeba zkrátit dobu přechodu - proto dd. Jindy, když byla obě pole OK, šlo použít dlouhé cp + opakovaný a finální rsync.
Samozřejmě nejraději postupně zvětšuji/přidávám do pole disky a nechám raid, aby si to celé zařídil za běhu. To bohužel u raid10 zatím nejde, veliká škoda...
>S těma hardlinkama je to pakárna a je to hlavní důvod, proč jsem zálohy přemigroval na btrfs, protože tam snapshoty na rozdíl od vytváření hardlinků nemají takový overhead.
V backuppc slouží ty hardlinky k deduplikaci jednotlivých souborů. Ale snapshoty se budou samozřejmě hodit, až je zastabilizují.
ČLÁNKY DO MAILU