Hur man verifierar att TRIM når SSD-enheter bakom en NAS-kontroller

Lyckad fstrim-utdata bevisar inte att TRIM nådde varje fysisk SSD. Slut-till-slut-verifiering kräver matchning av filsystemets inskickning med bevis från lägre lagringslager.

På en NAS kan borttagna block passera genom filsystem, kryptering, LVM, mjukvaru-RAID, en kontrollerdrivrutin och en virtuell disk innan någon SSD ser dem. Denna procedur skiljer annonserat stöd från observerad discard I/O, visar var hårdvaru-RAID kan dölja vägen och undviker destruktiv testning på en aktiv pool.

Vad räknas som bevis för att TRIM nådde SSD:n?

TRIM-verifiering har flera nivåer. Ett filsystem kan acceptera en FITRIM-förfrågan, Linux blocklager kan utfärda discard I/O, en drivrutin kan slutföra den, och en kontroller kan fortfarande översätta, absorbera eller avvisa kommandot innan en medlem SSD tar emot det.

De potentiella discard-byten som rapporteras av fstrim beskriver intervall som skickats från filsystemet till blockstacken. De intygar inte kontrollerns vidarebefordran, fysisk flash-radering eller ens att upprepade körningar representerar nyåtervunnen plats.

Använd det starkaste uttrycket som din lägsta observation stöder. En blockspårning kan bevisa att Linux utfärdade discard till en synlig enhet; endast mål- eller kontrollerteleskopi kan utvidga det påståendet bortom en dold RAID-gräns. Vad SSD:n gör därefter hör till SSD:s skräpinsamling, inte till FITRIM-utdata.

Kartlägg lagringsvägen innan du testar något

Börja med den monterade datasetet eller delningen, och lös sedan ut dess faktiska blockväg. En vanlig kedja är filsystem, krypterad mapper, logisk volym, mjukvaru-RAID, kontrollerns virtuella disk och fysisk SSD. Din NAS kan utelämna flera lager eller helt dölja de slutliga medlemmarna.

Registrera monteringspunkt, filsystem, enhetsträd, kontrollermodell, drivrutin, firmware, driftläge, RAID-nivå och SSD-modeller. Orden HBA, JBOD, pass-through och RAID-läge beskriver presentationsval, men de garanterar inte identiskt discard-beteende över olika kontroller eller firmwareversioner.

Identifiera också kommandofamiljen. Linux kallar operationen discard; SATA-enheter får vanligtvis ATA Data Set Management med TRIM, SCSI-lagring använder UNMAP och NVMe använder deallokeringssemantik. En brygga eller kontroller måste översätta och vidarebefordra relevant operation för den fysiska enheten.

Kontrollera annonserat discard-stöd på varje synligt lager

Kör lsblk -D och följ enhetsträdet från det monterade filsystemet mot den lägsta enhet som Linux exponerar. Icke-noll DISC-GRAN och DISC-MAX värden betyder att lagret annonserar discard-funktion; nollvärden identifierar ett lager där stöd saknas eller är dolt.

Linux discard-kögränser definierar noll granularitet eller max som ingen annonserad discard-stöd. Kontrollera motsvarande /sys/block/DEVICE/queue/-värden istället för att bara läsa den översta virtuella disken.

Mapper-inställningar kan fortfarande undertrycka pass-through. En praktisk guide till TRIM genom lagringsstacken visar kontroller för device-mapper-tabeller och discard-gränser. Behandla icke-nollvärden som tillåtelse att fortsätta testa, inte som bevis på att ett kommando nådde en medlem-SSD.

Generera en kontrollerad discard och spåra den lägsta synliga enheten

Använd en engångstestallokering inom ett friskt monterat filsystem, inte ett rått sektorsområde. Säkerställ att allokeringen är bekräftad, ta bort den, synkronisera filsystemet och kör en riktad fstrim medan du spårar de relevanta blockenheterna. Undvik att testa under ombyggnader, skanningar, degraderade tillstånd eller tunga skrivningar.

En fokuserad procedur för granskning av discard pass-through använder enhetsstatistik och blktrace för att skilja discard-händelser från skrivningar. Verifiera kommandofälten mot de verktyg som är installerade på din NAS, eftersom spårningsutdata och fältpositioner kan variera mellan versioner.

1. Lös monteringspunkten till varje OS-synlig underliggande enhet.
2. Fånga discard-räknare och aktuella kökapaciteter.
3. Starta ett discard-filtrerat spår på den lägsta relevanta enheten.
4. Skapa, genomför och ta bort en engångstestallokering.
5. Kör en fstrim mot den monteringspunkten.
6. Stoppa spårningen och jämför händelser på varje lager.

Ett discard-problem på en övre mapper eller RAID-nod bevisar bara att förfrågan nådde den noden. Ett discard-problem på den lägsta synliga medlemmen är starkare. Drivrutinsavslut visar att Linux mottog avslut, men det kan fortfarande inte avslöja dold trafik från kontroller till disk.

Veta var bevisen slutar bakom hårdvaru-RAID

En hårdvaru-RAID-kontroller kan presentera en virtuell disk samtidigt som medlems-SSD:er och deras kommandoströmmar är osynliga för Linux. I den layouten kan blockspårning nå kontrollerns drivrutinsgräns men kan inte fastställa vilken fysisk SSD som mottog TRIM, UNMAP eller en översatt motsvarighet.

Ett testat exempel på SSD:er bakom RAID-kontroller visade noll annonserad discard-kapacitet i RAID-läge för den undersökta kontrollern och en annan exponering i JBOD-läge. Behandla det som ett modell-specifikt diagnostiskt mönster, inte en regel för varje kontroller.

Utöka beviset endast med pålitliga kontrollloggar, målprovisioneringsstatus, protokollspår eller dokumenterade fysiska diskräknare. SMART-data har ingen universell TRIM-mottagningsräknare. Om kontrollern inte exponerar lämplig telemetri är det ärliga resultatet ”discard nådde den kontrollervända enheten; fysisk mottagning är obekräftad.”

Tolka resultatet utan att överdriva

Använd den lägsta bekräftade observationen för att välja nästa åtgärd. Tabellen separerar kapacitet, observerad trafik och fysisk mottagning så att ett rent fstrim-resultat inte tyst kan bli ett starkare påstående än vad bevisen stödjer.

Ett godkännande gäller endast för det testade filsystemet, stacken, kontrollerns läge, firmware och SSD-modell. Kontrollera igen efter en kontrolleruppdatering, RAID-migrering, krypteringsändring eller ombyggnad av lagringslayout eftersom varje ändrad lager kan ändra discard-exponering eller översättning.

Gör inte verifiering till dataförlust

Kör inte råa discard-kommandon mot en aktiv NAS-pool. blkdiscard dataförlustgräns är tydlig: kommandot tar bort block i det valda intervallet, och dess force-alternativ kan kringgå exklusiv åtkomstskydd.

Lita inte på att läsa nollor efteråt. Linux dokumenterar att post-discard-läsbeteende varierar och kan vara opålitligt även när en enhet annonserar noll-retur-beteende. En kontroller kan också emulera resultatet utan att exponera fysisk NAND-hantering.

Om fysisk bekräftelse är obligatorisk, använd en isolerad engångs-SSD eller en temporär logisk enhet med testade säkerhetskopior och kontrollerspecifika instruktioner. För en produktions-NAS är den säkra slutsatsen ofta avgränsad: bevisa borttagning till den lägsta observerbara gränsen, dokumentera vad som förblir dolt och riskera aldrig poolen bara för att förvandla "overifierad" till "ja."