Saker som 'Synologys egna Hybrid drive' precis som alla andra NAS-tillverkares namn på samma sak är bara namn på en bunt script till mdadm inne i ditt GUI - i botten har du en mdadm-raid som gör grovjobbet ändå.
---
Vet inte om din variant kör ext4 eller BTRFS - men troligen den senare.
Hade du kört BTRFS native (dvs. inte liggande på en mdadm-RAID som det gör nu idag för dig) så hade man kunnat gjort dom övningarna som du önskade.
Med en enkel "btrfs device delete /dev/sdx /mnt" och antal timmar till några dygn senare hade disken varit friställt.
Att det tar tid beror på att först packas filsystemet och sedan har man 2 parallella RAID med olika antal diskar där den med 1 disk mindre exkluderar den disken du vill ta bort och så flyttar det över stripe för stipe och krymper den RAID med fler diskar allt eftersom och fyller på den RAID med färre diskar och till sist är det RAID:en med större antal diskar helt tom och försvinner och därmed frikopplas också disken rent logiskt.
en annan funktion man kunnat använda är btrfs dev replace sdx /mnt för att just ersätta en felfungerande disk.
Men inget av ovanstående kan göras då BTRFS ligger på en mdadm-RAID och därmed ser bara en virtuell disk och har ingen kontroll över de fysiska enheterna. BTRFS kan mycket väl minska sin filsystem i storlek men ditt problem är att få mdadm-RAID att stripa om sin RAID så att den felfungerande disken friställs.
Det skulle kunna vara en serie liknande:
först krympa din BTRFS-filsystem så nära dess av filer upptagna storlek som möjligt - det finns funktioner för det i btrfs och den ompackningen kan ta flera dygn innan nästa steg om filerna/chunken är utspridda på diskytan
resize2fs -M (vet dock inte om det fungerar direkt med BTRFS - men btrfs har funktioner att krympa sig till mindre storlek om det finns plats - läs dess manual)
därefter om det är tillräckligt med diskplats kvar även utan den felaktiga disken:
mdadm ... --grow --raid-devices=3 --backup-file=/tmp/backup (när man går från 4 diskar till 3 diskar)
(notera att "--backup-file=/tmp/backup" (sökvägen förstås justerad till aktuell disk) är extremt viktig och skall läggas på annan fysisk disk (usb-disk) som _inte_ är kopplad till den mdadm-RAID man jobbar på - lagringen av filen krävs då medans den rotar runt med mdadm-RAID så finns inte filerna som behövs för att göra en korrekt start i själva RAID och får man en strömavbrott i processen (som kan ta dagar att slutföra) så är RAID:en förlorad om man inte har denna disk med backupfilen tillgänglig)
japp - storleken kan alltså växa negativt till färre diskar men frågan är om man kan styra explicit vilken disk som inte skall användas (dvs rensas på sitt innehåll med re-striping - dvs. du vill att den disken med re-allokerade sektorer skall friställas, inte någon annan...)
Du få läsa manualen för mdadm _noga_ surfa och titta på ett antal användar-case som gjort samma sak mha Google etc.
Jag skulle inte göra något av det utan full och verifierad kopia av all data på extern USB-disk innan som backup, och helt kallt räkna med att ta bort din RAID i NAS och börja från början igen och ladda tillbaka allt igen - kort sagt du skall vara redo för det!...
Dessutom skulle jag köpa mig en RPI4 och leta fram en bunt gamla USB-diskar där man kan skriva vad som helst i eller rent av 4 stycken USB-stickor i en USB-hub och prova först med olika lösningar och se om det går att få den önskade utbytet - det handlar om att göra saker i rätt ordning här.
(med smartctr kan man faktiskt skicka kommandon som gör att diskar får läsfel etc. när olika adresser läses, men förmodligen bara fungerar på just snurrdiskar och dessa kanske dessutom måste vara kopplade med SATA direkt till moderkort eftersom man använder uråldriga AT-kommandon direkt till en gång i tiden WD-HD-kontroller absolut lägsta nivå ända från ST512-tiden för att skriva bitmönster som är felaktiga och därmed genererar läsfel när det läses nästa gång... - det är mycket varning på dom kommandona och man kan förstöra diskdrivern permanent av detta)
