Har på en server (ubuntu server headless) exprimenterat med btrfs RAID5 på 7st 300 GB SAS-diskar - är mycket väl medveten att BTRFS RAID inte är klassad 'produktionsredo' och i raiden satt en disk som det börjat gnällas om reallokerade sektorer - det för typ 1.5 år sedan...
För några veckor sedan började dmesg gnöla om SMART-error efter att ha varit helt tyst i 1.5 år typ och kontrollern hade kickat disken - med andra ord ingen redundans.
Problemet med HP:s P400-kontroller är att varje disk är en egen logisk volym då denna inte tillåter IT-mode - och att bara byta disken och hoppas på det bästa fungerar inte.
Satt i valet och kvalet hur jag skulle hantera detta och beslutade att innan jag tog bort någon disk, efter att syncat backupen så skulle jag reducera RAID:en med en disk - den trasiga - vilket görs med 'btrfs dev del /dev/sdx /sökväg_till_volym' - då byggs hela diskinnehållet om genom att ha två RAID5 aktiva parallellt - en med 7 diskar (och en av diskarna saknas) och en med 6 diskar. Först börja den att packa alla extension och sedan flytta över extension från 7-disk RAID5 till 6-disk RAID5 och likadan procedur med all system metadata (som också var RAID5) då volymen är relativt liten och tillsammans knappt 2 TB så var det ganska snabbt gjort då flödet var kring 550 MB/s om man räknade ihop läs och skrivtakt-takt.
Stängde ned maskinen, mökade i p400:s bios för att få den dåliga disken utbytt med en ny.
Startade upp - jaha då var det en disk till som blev utkickad - dvs. P400 ville inte ha att göra med den längre, skumt såg inget om i dmesg att en disk till var på G... - en 6-disk RAID5 utan redundans - så jag gjorde om proceduren ovan (efter att kontrollera att ha plats att krympa en disk till) - ut med den utkickade disken - mök i P400-bios för att få den nya i systemet igen.
Starta upp och med 'btrfs dev add /dev/sdx /sökväg_till_volym' 2 gånger för båda bytta diskarna och sedan körde jag 'balance' - eftersom systemet var redan i RAID 5 så förstod BTRFS att de två tomma diskarna skulle användas och på samma sätt som tidigare så är det i konverteringen 2 RAID5-system parallellt (och därmed tål en strömavbrott mitt i proceduren då det också är transaktionshantering - dvs inget finns 'giltigt' förrän en transaktion är gjort ) - en med 5 diskar och en med 7 diskar där extensions bytte plats med varandra och när det var klart så körde jag sedan rsync med -c flaggan och jämförde med backuppen - inte en fil fel någonstans.
I det avseendet så klarade det sig riktigt bra och trots 2 diskhaverier omedelbart efter varandra - visst det är inte automatiskt som en HW-raid där man bara trycket ut den gamla disken och trycker in den nya och så börja det synka - men inte ohanterligt heller om man gör det enligt en viss procedur, sedan är frågan om HW-RAID hade lyckats med diskbytena om den andre disken hade havererat under proceduren när den synkade för den första disken - nu när jag gjorde reduceringen i två steg så fick man en medföljade redundans nedåt med diskantal, men hade det också varit ett läsfel på den disken som sedan föll bort i andra steget redan i första steget så...
Då är det värre med den jag stångar med nu - en annan 4 diskars RAID5 på en NAS med mdadm där jag fick 'write' error och 'read-error' (dvs mdadm rapporterade det i dmesg - dvs. nivån under använda filsystem) utan att något om det syntes i diskarnas SMART - jag provläste var disk i RAID separat med 'dd' eftersom jag hade läsfel - och på 8TB diskar så tar det en stund - inga fel på någon av dem - provade läste på md3 som var själva RAID som logisk volym exklusive filsystem - läsfel ca 6 TB in på volymen, och det var inte få sektorer som den vägrar att läsa med IO-fel - vad i helv...
Problemet med mdadm när det börja vara fel är att den är tyst som en mussla - man får reda på att något var fel och vilken LBA - men inte hur eller varför...
Nästa steg var att med rmlint jämföra filerna på den rsync:ade backupdisken med filerna på RAID och helt enkelt ta bort filerna som är lika från RAID då det började lukta logisk fel i själva RAID och att det eventuellt hade något att göra med 8TB gräns (det snurrar på en 32-bitas ARM-NAS, normalt skall det inte ge problem förrän vid 16 TB och volymen i fråga var satt till 15 TB av just den orsaken) - det tog ju förstås ett tag då det var ca 8 TB och ca 4 miljoner filer och det som var kvar var den senaste skrivna borg-backupen med runt 40000 småfiler och efter jämförelse så var det ca 12 kvar av dem och försökte man kopiera eller på något sätt läsa dem så blev det IO-error
Tog bort filerna och sedan började jag provskriva hela partitionen genom filsystemet med zero-filer mha. dd för att se om jag får IO-error när jag skrev filer - och det fick jag efter 6-7 TB och problemet är att dmesg börja spotta felmeddelande från MDADM att den inte kan skriva men det ger inte IO-error till filsystemet och applikationen ovan och stoppar denna (var i gränsen mellan MDAM och BTRFS det skiter sig vet jag inte) - med andra ord skriver det silent error till diskarna, medans försökte man läsa filen via filsystemet efter så blev det IO-fel...
Det är i filsystemvärlden en katastrofproblem!!! och det verka sitta i mdadm - en RAID-system som anses vara väldigt stabil!!
så, jag avbröt det hela - tog bort hela partitionen då jag nu antar att hela mdadm RAID är kaputt ända ned till grunden när det hittar på fel som inte finns (eller för att det viker runt vid 8TB-gränsen) - skapade en ny partition, ny mdadm RAID5 och ovanpå denna BTRFS med checksumma aktivt och nu kör jag tillbaka en jäkla massa filer och nu tänker jag köra filsystemet stumfull och sedan ta bort allt med rmlint igen och se om något blir kvar - dmesg -T -w är också igång under processen och vi får se om det händer något när man går över 8TB igen...
Om det fortfarande är ett problem så är det bara att inse att den här nasen är att skrota och aldrig mer köpa något som är mindre än 64-bits OS på i fortsättningen (förvisso är förtroendet redan brutet när det gäller NAS och 32-bitars system och framförallt på ARM-plattform - och saken är att det hjälper inte att byta 'märken' - fel som finns på en plattform finns också på annan tillverkares plattform eftersom de använder samma linux-kärna och generation samt klustret med hjälpprogram och alla dessa tillverkare gör väldigt lite för att fixa felen själva, sitter och trycker och hoppas att någon annan gör det åt dem - kommer ihåg ext3-ext4 debacklet och journal-hanteringen där och disken blev oehört seg till helt tvärstopp om man försökte fylla disken över 75-80%... och var samma fel hos alla NAS-tillverkare på den tiden, och mirakulöst så löste alla problemet på närmast dagen samtidigt - efter 2 års gnäll och spyende på respektive tillverkares forum där många rage-quitade och hoppade till annat märke för att upptäcka att problemet var samma även hos dem... och de mer luttrade inkl. jag körde på ext3 utan journal... och tittade på spetaklet)
