Skrivet av grogt:
Tyvärr är det uppförsbacke att börja använda btrfs med snapshots och subvolymer. Det kräver att man sätter sig in i hur det fungerar för att det ska bli riktigt bra.
Tycker dock inte att BTRFS är så krångligt som det låter ovan.
det är typ 3 haranger man behöver komma ihåg - under förutsättning att man är på en lagring som är BTRFS.
"btrfs su create mappnamn"
för att göra en ny tom subvolym där man kan lägga in mappar och filer
"btrfs su snap mappnamn_1 mappnamn_2"
skapar en ny subvolym av en redan existerande subvolym mappnamn_1 till ny subvolym "mappnamn_2" med exakt samma innehåll som mappnamn_1 - det är detta som brukar kallas för "snapshot" och är en process som går på typ 1 sekund att utföra och kanske tar 50 kByte extra i diskutrymme. Obs! det kan bara göras inom samma logiska BTRFS-volym - vill man ha skrivskyddat så lägger man till "-r" i kommandosträngen och då kan inget alls inom den skapade subvolymen mappnamn_2 ändras - inte ens tidsstämplar när man läser filer... Snapshot på denna sätt tar allt inom subvolymen utom andra ytterligare subvolymer i mappträdet som är inlagda inom aktuella subvolym och dessa lämnas bara som en mappnamn utan innehåll i sig i filträdet i den nyskapade subvolymens mappträd.
- detta möjliggör att om man inte har någon skapad subvolym alls i sin BTRFS-lagring och redan lagt en massa filer där - så kan man göra en subvolym med allt innehåll som redan inlagt i roten till en kopia som subvolym (snapshot) med "btrfs su snap . mappnamn_3" och allt som fanns på BTRFS-volymens root finns nu också i mappnamn_3 utom det som ligger i subvolymer.
Roten på BTRFS-filsystemet är nämligen också en subvolym med namnet "."
Som överkurs man man i samband med monteringen av BTRFS-volymen välja med option vilken av alla subvolymer som skall bli BTRFS-volymens root.
Den sista kommandot som man kanske använder lite mer ofta är:
"btrfs su delete mappnamn_2"
- det är som den säger - den tar bort subvolym mappnamn_2 med hela underliggande mappträdet i ett blink , det fins ingen ånger eller räddningsmöjlighet eller extra fråga när det väl exekveras utan subvolymen är bort för alltid på ett ögonblick, och den tar också bort skrivskyddade subvolymer utan varning!!.
Vill man tömma normala filträn tex. efter en rsync-spegling med tex "rm -r -d mappnamn" och hårdlänkade filer mellan en uppsättning mappar med backupfiler (också skapade med 'rsync' tidigare) så vet de som provat att det kan kan ta åtskillig tid få bort mappträdet när det handlar om hundratusentals till miljoner filer och det är kanske över TB med data att radera - med att lägga rsynckopian på en subvolym så tas trädet bort på en sekund¹ när den är förklarad inaktuell.
En sak att tänka på är att hårda länkar kan inte kopplas mellan olika subvolymer då var subvolym är i princip en egen virtuell logisk lagring/filsystem med sin egna inoder etc. och därför kan inte hårda länkar peka mellan olika subvolymer i BTRFS - bara inom själva subvolymen.
Det fins ingen rangordning eller hierarki (mer än rent numerisk internt för att skilja dessa åt) mellan subvoymerna i BTRFS till skillnad från ZFS utan skapade subvolymer kan raderas i helt annan ordning än ordningen de skapades i - dessa är alltså inte beroende av någon 'master' eller 'dataset' att utgå ifrån och varje subvolym (om de inte är skrivskyddade) kan modifieras, ändras, tömmas eller fylla på med ny data helt fritt utan att det påverkar någon annan subvolyms mapp och fil-innehåll.
I BTRFS finns det en del grejor som är svår att vara utan när man väl vant sig vid det - och en av dem att kunna kopiera väldigt stora filer (läs diskimages) mellan subvolymer utan att kopiera mer än dess metadata, vilket gör att en 1TB-stor fil tar inte mer än max några sekunder att kopiera och utan att det tar mer plats på disken. I terminal med 'cp' så är det "cp --reflink=always filnamn1.img filnamn2.img" och det görs metadata för den nya filer som pekar på samma datablock som orginalet istället för att kopiera allt till dubbel upplaga av data och ta upp dubbla diskutrymme i plats samt tar tid att utföra med kopiering av data. - tyvärr är inte 'reflink' defaultbeteende i cp lika lite som 'sparse'
Kör man i CLI-terminal Midnight Commander så sker det automatiskt 'reflink' vid kopiering av filer när det går och jag var väldigt förvånad första gången när jag skulle kopiera ett filträd på flera hundra GB och kanske 100000 filer - när det var klart 30 sekunder senare istället för kanske över timmen senare och det tar inte upp någon extra diskplats mer än för den nya metadatan det skapade för filerna...
BTRFS erbjuder också att kunna komprimera filerna medans det sparas på volymen och vill man ha en specifik komprimerande mapp (och det behöver inte vara en separat subvolym) så använder man 'chattr +c mappnamn' på en skapad eller existerande mapp och allt som senare läggs i denna mapp och alla undermappar som skapas kommer att komprimeras utan speciellt stor upplevd prestandakostnad (komprimeringen är multitrådad på kernelnivå när den arbetar) - det går att att välja typ av kompressionsalgoritm och kompressionsgrad - men det är annan historia - men jag har använt zstd på låg kompressionsgrad för tex. videoflöden från SDR-mottagare med typisk kompressionsgrad 50% vilket är viktigt båda i avseende bandbredden mot lagringen (istället för 350 MB/s går ned till 175 MB/s kontinuerligt under timmar) och det faktum att man får in dubbelt med datamängd på samma lagring.
- lagrar man tex. (RAW) diskimages tagna från SSD/NVMe-lagring med tex 'dd' eller 'ddrescue' så kan filsystemkompression spara väldigt mycket diskutrymme utan att behöva koda om dessa i format som VHDx eller andra format som diskimageprogram gör i windows, eller att komprimera dessa separat med lämplig kompressionsprogram - och här med fallen SSD/NVMe-lagring utnyttar man att windows kör 'TRIM' på filer som raderas och den vägen är blocken som höll den raderade datan tidigare utlästa som '0'-fyllda block i SSD/NVMe och lätta att komprimera. Lagrar man diskimagen dessutom med '--sparse' i samband med 'dd, ddrescue' så spars inte 0-fyllda blocken i diskimagen alls utan hanteras bara i metadatat och man spar lite ytterligare utrymme då 0-fyllda blocken inte behöver komprimeras alls.
---
BTRFS har inte inbyggd deduplicering men man kan köra dedupliceringsprogram som 'bees' som sidokanalsprogram och på låg nivå, under den synliga filsystemet deduplicerar med variabel block-storlek och ned till 4-K block dynamisk (även typ 1 GB med RAM fast disken är 18 TB stor) samt gör sparse-sekvenser på filer med bara 0-fyllda sektorer och den vägen kan göra att lediga utrymmet i filsystemet kan öka dramatisk när man tex. hanterar många diskimages och givetvis fungerar detta också på komprimerande mappar.
I många fall ger deduplicering betydligt större frigjord lagringsyta än att tex köra med kompression. Det har dock en kostnad - tex. linjärt skrivna filer som diskimage - kan efter att 'bees' körts, ge mycket läshuvudarbete på mekaniska diskar när det läses ut igen då filen i fråga blivit fragmenterad då mer eller mindre stora partier av filkroppen har kopplats ihop med andra likadana block på andra filer på helt annan plats på disken och det kan bli mycket sökningar - detta är en kostnad som gäller i de flesta sammanhang när man har deduplicering på blocknivå.
¹ efter att 'btrfs su delete' har körts så är det en 'garbage collector' i BTRFS som härja runt på lagringen en stund - men det är fortfarande mycket, mycket mindre med läshuvudrörelser på en mekanisk disk än om man skulle ta bort samma filträd med tex. 'rm -r -d mappnamn'
