Hvordan planlegge diskvedlikehold for tynne disker hvis TRIM på Windows er deaktivert

Oversikt

Hvis du ofte sletter og oppretter store datasett på nytt i et Windows-miljø (for eksempel: Sikkerhetskopier til disk), kan en foregående slettehandling resultere i et høyt antall UNMAP kommandoer på matrisen. Hvis du skriver om den samme diskplassen, kan skriveytelsen bli dårlig, fordi de innkommende skriveoperasjonene venter på UNMAPs som skal behandles. UNMAPs Returner diskplasselementer til diskutvalget på arraysiden.

Operativsystemmekanismen som driver denne logikken for lagringseffektivitet kalles "TRIM." Hvis TRIM er aktiv, og hvis du sletter en blokk på filsystemet, genererer filsystemet (NTFS) metadata om den frigjorte plassen og sender den ned I/O-stakken. På disknivå i I/O-stakken avgjøres det om måldisken er ATA-tilkoblet. I så fall en ATA TRIM Kommandoen sendes til objektet for den fysiske disken. Hvis disken er en SCSI-disk, konverteres TRIM til en SCSI UNMAP.

Hvis du sletter og skriver om den samme datadelen på nytt, er lagringseffektivitetsaspektet ved denne retur-til-utvalg-mekanismen begrenset. Under disse omstendighetene kan du enten ha valgt å deaktivere TRIM på NTFS-nivå i varigheten for den respektive produksjonsjobben, eller deaktiver TRIM helt og gjenvinne eventuelle blokker på et annet tidspunkt manuelt.

Det resulterende spørsmålet er hvordan du kan sikre at diskene fortsatt er plasseffektive på lang sikt?

Begrensninger

Vær oppmerksom på at det er noen begrensninger som må vurderes før du oppretter en løsning.

1.

For å utløse retrim på en enhet, kjører du vanligvis defrag-kommandoen med alternativet /L. Når du deaktiverte TRIM ved hjelp av "fsutil behavior set disabledeletenotify 1," Du kan være under inntrykk av at trim eller unmap bare er deaktivert ved sletting , og at Retrim fungerer som forventet. Slik er det ikke. Retrim-handlingen i defrag er en mekanisme som tildeler en tom sparsom fil og deretter kaller FSCTL_MOVE_FILE for å flytte dataene. Se «Windows Internals 7», «Part II», s. 644 ff for ytterligere detaljer. Den resulterende virkemåten innebærer en slettehandling under panseret. Dessverre, hvis disabledeletenotify is "1," den retrim Kommandoen lykkes fortsatt. Det resulterer ikke i unmaps.

Sekvensen for å få tilbake lagringen må derfor inneholde et trinn for å aktivere TRIM før defrag kjøres.

2.

Videre, hvis du har deaktivert TRIM På systemet globalt, aktiver det, defragmenter og deaktiver det igjen, deaktiveringsprosessen kan kollidere med ufullstendig retrim-kommandoutførelse, selv om kommandoen har returnert til ledeteksten. Da vi labtestet dette på Windows 2019, fant vi ut at vi måtte vente et par sekunder før vi satte inn disabledeletenotify til "1" igjen. Vi tror at dette er et resultat av et samspill mellom defrag kommandoen og optimizer-tjenesten i bakgrunnen.

3.

Hvis du planlegger TRIM ved hjelp av Drive Optimizer, krever standard Explorer-menyen en planlagt oppgave kalt "ScheduledDefrag" (/ Microsoft / Windows / Defrag) i oppgaveplanleggeren. Hvis du endrer oppgaven, oppdager Drive Optimizer dette faktum og ber om å gjenopprette standardinnstillingene før du kan fortsette. Hvis du deaktiverer oppgaven, kan du fortsatt kjøre defragmenteringskommandoene manuelt, men du kan ikke planlegge dem.

4.

Dette "ScheduledDefrag" oppgaven kalles også i System Maintenance (Control Panel\All Control Panel Items\Security and Maintenance\Automatic Maintenance).

5.

Hvis du deaktiverer TRIM, den UNMAP Kommandoflyten til de nedre lagene i I/O-stakken stopper umiddelbart. Dette er forventet atferd. Hvis du over tid observerer at den tildelte plassen vs. den brukte plassforskjellen blir for stor, kan du enten (1) må gi TRIM/UNMAP kommandoflyt fra den sparsomme filbehandlingen mer tid, eller (2) kjøre intervensjonen oftere.

Løsning

Som et resultat anbefaler vi at du lar disse systemstandardinnstillingene og oppgavene være som de er, og i stedet vurderer å opprette en ny oppgave i oppgaveplanleggeren, som:

1. Gjør TRIM ("fsutil behavior set disabledeletenotify 0")
2. Kjører defrag /l against all drives ("defrag /C /L")
3. Venter til resultatkommandoene er sendt til matrisen ("timeout /t 60")
4. Deaktiverer TRIM again ("fsutil behavior set disabledeletenotify 1")

MERK

Verdien for tidsavbrudd i trinn 3 er en interpolering av laboratorietester. Bruk dette som utgangspunkt. Hvis du oppdager at avvik mellom verdiene for tildelt kapasitet på matrisesiden og filsystemet som ble rapportert brukte kapasitetsverdier, bygges opp, kan det hende du må bruke større verdier, for eksempel 300 sekunder (5 minutter) og enda mer (3600; 1 time). Alternativt kan det hende du må kjøre oppgaven oftere; dvs. daglig i stedet for ukentlig. Årsaken til at disse avvikene kan bygge seg opp er forklart i begrensningene (5) ovenfor.
 

XML-oppgavemal

I det følgende gir vi deg en mal som du kan importere til en oppgaveplanlegger som du kan bruke som grunnlag. Kopier og lim inn XML-koden nedenfor til en fil, plasser filen innen rekkevidde for serversystemet du vil konfigurere, og bruk handlingen Oppgaveimport til å importere oppgaven. Oppgavemalen nedenfor heter DellSanDiskMaintenance. Den kjører de ovennevnte fire trinnene ukentlig, på en lørdag klokken 20:00 (8 pm), og plasseres i roten til planleggeren, for eksempel:

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.6" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Source>Dell Technologies</Source>
    <Date>2023-07-07T09:21:50.4883878</Date>
    <Author>Dell Technologies</Author>
    <Description>This task is an example of how to optimize thin SAN drives, if TRIM is globally disabled on the system.</Description>
    <URI>\DellSanDiskMaintenance</URI>
    <SecurityDescriptor>D:AI(A;;FA;;;BA)(A;;FA;;;SY)(A;;FRFX;;;LS)(A;;FR;;;AU)</SecurityDescriptor>
  </RegistrationInfo>
  <Triggers>
    <CalendarTrigger>
      <StartBoundary>2023-07-01T20:00:00</StartBoundary>
      <ExecutionTimeLimit>PT2H</ExecutionTimeLimit>
      <Enabled>true</Enabled>
      <ScheduleByWeek>
        <DaysOfWeek>
          <Saturday />
        </DaysOfWeek>
        <WeeksInterval>1</WeeksInterval>
      </ScheduleByWeek>
    </CalendarTrigger>
  </Triggers>
  <Principals>
    <Principal id="LocalSystem">
      <UserId>S-1-5-18</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>false</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
    <UseUnifiedSchedulingEngine>true</UseUnifiedSchedulingEngine>
    <MaintenanceSettings>
      <Period>P1D</Period>
      <Deadline>P4D</Deadline>
      <Exclusive>false</Exclusive>
    </MaintenanceSettings>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT4H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="LocalSystem">
    <Exec>
      <Command>%windir%\system32\fsutil.exe</Command>
      <Arguments>behavior set disabledeletenotify 0</Arguments>
    </Exec>
    <Exec>
      <Command>%windir%\system32\defrag.exe</Command>
      <Arguments>/C /L /U</Arguments>
    </Exec>
    <Exec>
      <Command>timeout</Command>
      <Arguments>/t 60</Arguments>
    </Exec>
    <Exec>
      <Command>%windir%\system32\fsutil.exe</Command>
      <Arguments>behavior set disabledeletenotify 1</Arguments>
    </Exec>
  </Actions>
</Task>