Skrivet av scienta:
Jo, det är ju så. Jag gav upp den idén då jag inte vill riskera huvudvärken. Just nu testar jag BTRFS och duperemove. Inte helt säker på att deduplicering är rätt väg att gå än, men känner att det är värt att undersöka ändå.
För blockorienterad deduplicering kika på 'bees'. Den gör deduplicering med variabel blockstorlek på 4k-sektornivå 'under' den logiska filsystemet även med rätt human RAM-förbrukning som 1 eller 4 GB oavsett diskstorlek och går som sidkanal i bakgrunden och skannar alla transaktioner med filer som ändras och läggs till. Mängden RAM bestämmer hur pass små block man går ned till i huvuddelen av deduplicering men har ändå ett träd från 4k block till väldigt stora block som fylls på och uppdateras dynamisk med vad för typ av data den läser.
Det är en best-effort deduplicerare vilket gör att är det för många referenser till samma block eller blockedja eller annat strul så skippar den det och bygger på en ny. den är väldigt försiktig och kan det inte lösas med för BTRFS säkert sätt så hoppar den över dessa segment. - Den gör väldigt stor platsbesparande för tex. diskimage med snarlik innehåll eller standaruppsättning av OS etc. inom dessa diskimage/VM-images - dessutom gör den sparse-segment på filer med stora mängder '0' i sina sektorer/block-kedjor och dessa block tar ingen fysisk diskyta efter det utan emuleras tillbaka igen vid läsning. Fungerar också på komprimerande mappar/filsystem.
Har haft sådana snurrande på server i flera år och har inte sett att de ställer till med något som kan kallas för att skada eller korrumpera BTRFS-fislsystemet. Givetvis väljer man själv med programstart om det skall deduplicera eller inte och kan stängas av när som helst och när det startas igen så arbetare den från var den var sist när den stoppades. Det är ingen envägs-funktion på samma sätt som när man aktiverar deduplicering i zfs där man inte kan backa om man märker att det kostade för mycket prestanda, utan att skrota hela datasetet igen och börja på nytt.
Den använder blacke2 hashar vilket är lättare att driva än sha256 som zfs använder dig av.
Det fins en sak att tänka på - med deduplicering kan det bli oväntat mycket sökningar för tex. en stor fil som man kanske tänkte sig vara sekventiellt sammanhållande skriven men kan läsas tillbaka med betydligt lägre takt än förväntat för att den har deduplicerats och många av dess block ligger på olika ställen i filsystemet och delar fysisk plats med bitar från andra filer, så när man skapar/använder det på en volym så skall man ha 'archvie' in mind och inte på högpresterande lagring.
---
Det fins en sak att tänka på (och står på dess hemmsida också) - kör inte bees på volymer med bcache write-back mode aktiv på volymen (det överlever dock write-trough mode).
Det bero på att många SSD har buggar i sin firmware - särskilt äldre, klarar inte av skrivmönstret från bees och FTL-lagrets databas i SSD:n snurra ihop sig av de allt mer komplicerade referenserna som skapas med tiden av alla småsektorskrivningarna som bees gör och var skrivning går långsammare och långsammare (och det klagas i linuxkärnan och syns via dmesg att den hela tiden måste öka tidskonstanter på svartstid för diskarna) och till sist stannar helt - vilket brukar ske inom typiskt 12 timmar efter man startat bees första gången på en redan halvfull disk. - SSD som stannat är jätte-långsamma och knappt går att skriva någon data till och somliga fall hänger sig vid skrivförsök och försvinner och ofta måste man utföra en secure erase innan den kommer tillbaka igen med full prestanda - somliga nöjer sig med zerofill och delvis får tillbaka skrivförmågan i avseende fart och andra måste köras hela vägen med secure erase (som Samsung 830).
När man kör write-back på bache har jag lärt mig att ofta uppdaterad data som metadata aldrig läggs ut på den bakomliggande snurrdisken från bcache utan blir kvar i flashen/SSD¹ tills aktuella LBA anses för gammalt och synkas först då ut på bakomliggande lagringen för att göra mer plats för ny data i SSD och när SSD kraschar av ovan nämnda skäl så förlorar man metadata för BTRFS-volymen och innehållet på lagringsdisken går inte att rädda då när SSD:n fryser så är datat i denna helt massakrerad och bcache känner inte igen något av det.
Faktum är att bees med bcache kraschar SSD/NVMe med buggig FTL-hantering så effektivt att det kan använda för att testa SSD/NVMe-lagring tänkt för olika disk-cache funktioner i tex. en NAS. och den vägen sålla ut SSD/NVMe som potentiellt kan haverera i framtiden och man förlorar hela NAS-volymen om den körs i write-back mode den dan det händer...
¹ Det fins idag default ingen synkningsmekanism aktiverad i bcache som med jämna mellanrum som synkar innehållet mellan vilande nyaste datat i bcache:s SSD motsvarande emulerade LBA-adresser och bakomliggande lagringens motsvarande LBA-adresser. Hade det synkat med jämna mellanrum med rimligt kort intervall så hade förmodligen BTRFS överlevt en SSD-haveri i bcache-mode även vid write back mode i och med att det är transaktionshanterande och kan göra rollback i transaktionerna tills checksummor och innehåll stämmer överens igen och data till den punkten är intakt när filsystemet monteras igen.
