Det här med att återställa HDD till fabrikskapacitet... ?

Vad är det du förväntar dig?

Att en 3GB disk visar 2,71GB beror på om man räknar en kB som 1000 eller 1024 bytes. Hårddisktillverkarna använder den första definitionen eftersom det får deras diskar att verka större. Windows använder den senare, vilket i mina ögon är den korrekta.
Att du inte kan formatera en partition som är 2,71GB på en 2,71GB disk beror på att utrymme försvinner för att hålla reda på partitionstabell och annan metadata om disken. Ledigt utrymme på en partition är det utrymme du faktiskt kan använda för data.

Med tanke på hela din historia kring att du hållit på med detta så länge så borde du redan känna till detta. Du har aldrig kunnat använda hela hårddisken till nyttig data. När diskarna blir större så "försvinner" det också mer utrymme eftersom det i någon mån är kopplat till storleken på disken, men konceptet är långt ifrån nytt.

Kraftfullaste sättet att hantera partitionering är Gparted eftersom det kan fungera fristående så man inte blandar in ett vanligt operativsystem som kan komma i vägen för det man vill göra, om inte Gparted funkar är det nästan alltid hårdvarufel.
https://gparted.org/

TLDR.

Jag skulle koppla en disk direkt till moderkortet, inte via en RAID-controller eller via ett USB-enclosure.
Sen skulle jag köra sg_format på den och se vad som händer.

Om disken via ATA-kommandon uppger sig ha 2.5 GB som storlek på en disk som är flera TB stor och bara begränsad uppvisad litet antal LBA-sektorer så är det inte mycket sg-format, hdparm, sdparm mfl. sg_xx kommandon kan göra - utan nu är det på firmware-nivå i aktuella disken.

Innan SSDs kom var det ju WD velirapotor som var de snabbaste. Tills någon kom på att man kunde en vanlig 'större' hårddisk och lågnivå formatera för att köra på den inre spåren, för nästan intill samma prestanda för halva priset.

De är inte lågnivå formaterade på nåt knasigt sätt bara? Men visst håller med, bort med RAID kontrollern först och främst, koppla in diskarna till moderkortet direkt. Hur stora är det då? Att felsöka med en RAID controller är hopplös. slår vad om att desktop diskarna inte ens är certifiera att fungera med den? Vill inte gnälla, men är rädd att vid minsta fördröjning, t.ex. småvibrationer som gör att disken stannar av en stund för att skydda sig själv. Så kommer en hårdvaru RAID controller som förväntar sig enterprise diskar slänga ut desktop diskarna ur RAID settet.

Nåja jag skulle nog ta en en valfri modern linux liveUSB distro (t.ex. ubuntu) och kolla hur stor disken där är.
därefter googla på: +hdparm "ATA Secure Erase"

När du kört igång secure erase ritualen, vänta, vänta, vänta. tills det verkligen är klart, vissa tar väldigt lång tid på sig och det är fullt normallt att det spottas ut kernel fel under tiden.. men därefter en reboot med samma linux för att se hur stor disken är.

I min värld gör man alltid en "dd if=/dev/zero of=/dev/sdx bs=10240k status=progress" [1] på struldisken och det skriver diskens början med bara '0' en bit in på disken just för att utesluta sådana saker som att partitioner lurar systemet.

Men som redan nämnt så bör det göras på så 'dumma' diskkontroller som möjligt utan några ambitioner med RAID-strukturer etc. vilket ofta faktiskt är via en 1-disk USB-SATA diskdocka eller äldre MB som inte har några inbyggda RAID-ambitioner eller åtminstone vara väldigt säker på att dessa är helt avstängda på modernare kort - för hugger dessa på lagringens första sektorer för att dessa stämmer med en RAID-struktur så får man en virtuell volym presenterad vidare till OS där de allra första sektorerna på disken inte syns för den senare startad OS då BIOS döljer dessa.

Kör man via HBA så skall man vara väldigt säker på att de är flashade till IT-mode - annars kan de också hugga på en LSI-kompatibel RAID-struktur i början på disken och det som läses vidare ut från HBA:n är en logisk volym av disken där lagringens första sektorer också är dolda.

[1] där sdx är någon av sda, sdb, sdc etc. och man bör använda 'lsblk' strax innan så att man är säker på att köra mot rätt disk!! - och sedan köra en bit in på disken (och kan brytas med Ctrl-C när man tycker att det kört länge nog) för att vara säker på att MBR och GPT och eventuellt startsektorer på eventuella RAID-strukturer är helt borta.

Lågnivåformatering på riktigt som man gjorde med ST506/ST422-disk-kontrollerkort och på diskar med stegmotorer eller de lite senare voice-coil med separat skiva med servospår på DOS-3.1 tiden försvann ganska fort när IDE-diskarna tog över disk-gränsnitts standarden - på de första IDE-diskarna så kunde man fortfarande göra detta då de var i princip ihopbyggd ST506/422 disk med diskkontroller på samma kort på disken (och IDE-bussen var en förlängning av ISA-bussen med 74HC373/244 buffert-kretsar)

En modern IDE-disk kan inte formatera sig själv från allra första början hur mycket man än önskade det och beror på att servospåren för att läshuvudet skall kunna orientera sig måste assisteras fysiskt av externa mikroaktuatorer som med en kolv går igenom sidan på diskschassiet och trycker på läshuvudet medans den interna aktuatorn trycker emot så mycket det går och så steppar man i några nanometerssteg (en spårbredd på en disk är idag under 100 nm bred och en 'bit' skriven är under 10 nm lång, kanske 5-6 nm idag och förklarar varför man nu är kring 300MB/s på 7200rpm-diskar fast varvtalen inte är högre än tidigare)

titta på en WD-green (red, blue, gold) disk tillverkad på Tandon-plant 2010 - 2015 (idag nedlagt då HGST står för alla WD:s diskar idag) så finner ni en folielapp över ett hål i sidan som är från den processen

När man började med läshuvuden med flera läsdelar i samma huvud så räcker det med en masterspår som görs i samband när skivan tillverkas och resten av spåren kan skapas när en av läsdelarna i huvudet kan följa på den föregående spåret medans den nya skrivs - dock sker det inte med den firmware som sedan levereras med disken så den processen kan inte göras igen i efterhand.

Dock att skriva disken med '0' från början till slut med 'dd' kan 'renovera' en strulig snurrdisk (och SSD/NVMe också för den delen - som tex. att de blir snabbare igen då att skriva sekventiellt med '0' ger samma verkan som att köra TRIM på samma område - dvs. flashblocken bakom LBA-adressen kopplas ifrån adressen och kan ingå i flashblock-poolen efter radering) ) som tex. hänger sig eller har andra problem - för när man skriver sekventiellt så tittar inte diskkontroller på snurrdisken vad som fanns skrivet innan på diskytan (som kan ge problem om den läses för att det är för mycket fel i denna) utan det blir helt nya sektorer skrivna mellan sina synknings-block och man kan också den vägen bli av med 'pending sektors' som fins sedan tidigare registrerat i tex. 'SMART' då vid skrivning så verifieras alltid skrivningen med läshuvud strax efter skrivhuvudet att skrivningen blev korrekt och med tillräcklig styrka - eller om det inte går med flera omskrivningsförsök - blir reallokerad sektor.

jag har haft mer framgång med denna 'enkla' övning med 0-skrivning med 'dd' hela disken igenom än när man använder disk-tillverkarens egna verktyg i kontroll och reparation av lagring och beror på att dessa faktiskt försöker läsa först innan de skriver - men med sekventiell 'dd'-skrivning så frågar man inte ens om vad som fanns skrivet innan på diskytan när man skriver över den med nya datan.

När du säger shell så hoppas jag du menar SSH från en annan klient, inte det inbyggda i webbgränssnittet.
Skulle du kastas ut/din session återställas avslutas alla startade processer i den inbyggda webbterminalen på mindre optimalt sätt. Det är inte önskvärt när du ägnar dig åt en känslig räddningsaktion.

Om det skriver med 15 MB/s i genomsnitt och med bs=10240k blockstorlek (vilket betyder att det skriver i 10 MB-block som minsta blockstorlek sekventiellt) så skulle jag inte lägga ned så mycket mer krut på disken - normalt borde det vara minst 70 MB/s när den skriver nära centrum och kanske runt 140 MB/s när det skriver i ytterkant i den generationen diskar.

---

Även ssh stänger om man klipper förbindelsen - med 'nohup kommandoraden' kan man få programmet att fortsätta snurra även om terminalkopplingen försvinner

annars kan man prova med 'screen', 'tmux' (eventuellt måste installeras först, medans 'nohup' finns alltid) och motsvarande som håller kvar sessionerna i arbete och kan logga in senare igen även om terminalanslutningen bryts/stängs av

Javisst, men ssh avbryter i normala fall inte din session, med reservation för att ibland kraschar saker o ting.

TrueNAS webbgränssnitt kommer att kasta ut dig när den känner för det. Inom 15 minuter är inte ovanligt. Det är en finess, typ, inte en bugg. Då dör även ditt webbskal.

Med det sagt är tmux eller screen fortfarande bra tips när man gör känsliga saker.