Så här schemalägger du diskunderhåll för tunna diskar om TRIM på Windows är inaktiverat

Översikt

Om du i en Windows-miljö ofta tar bort och återskapar stora datamängder (till exempel: Säkerhetskopiera till disk) kan en föregående borttagningsåtgärd resultera i ett stort antal UNMAP kommandon i disksystemet. Om du skriver om samma diskutrymme kan skrivprestandan bli lidande eftersom de inkommande skrivningarna väntar på UNMAPs som ska behandlas. UNMAPs Returnera diskutrymmeselement till diskpoolen på disksystemsidan.

Operativsystemsmekanismen som driver den här lagringseffektivitetslogiken kallas "TRIM.” Om TRIM är aktivt, och om du tar bort ett block i filsystemet genererar filsystemet (NTFS) metadata om det frigjorda utrymmet och skickar det nedåt i I/O-stacken. På disknivå i I/O-stacken fattas ett beslut om huruvida måldisken är ATA-ansluten. I så fall ska en ATA TRIM skickas till det fysiska diskobjektet. Om disken är en SCSI-disk konverteras TRIM till en SCSI UNMAP.

Om du tar bort och skriver om samma dataavsnitt igen är lagringseffektivitetsaspekten för den här mekanismen för återgång till pool begränsad. Under dessa omständigheter kan du antingen ha valt att inaktivera TRIM på NTFS-nivå under varaktigheten för respektive produktionsjobb, eller inaktivera TRIM helt och hållet och återta eventuella block vid en annan tidpunkt manuellt.

Frågan som uppstår är hur du kan försäkra dig om att diskarna fortfarande är utrymmeseffektiva på lång sikt.

Begränsningar

Tänk på att det finns vissa begränsningar som du måste tänka på innan du skapar en lösning.

1.

Om du vill utlösa omtrimning på en enhet kör du vanligtvis defragmenteringskommandot med alternativet /L. När du har inaktiverat TRIM med "fsutil behavior set disabledeletenotify 1," Du kan få intrycket att trimningen eller avmappningen endast är inaktiverad vid borttagning och att retrimningen fungerar som förväntat. Så är inte fallet. Retrim-åtgärden i defragmentering är en mekanism som allokerar en tom gles fil och sedan anropar FSCTL_MOVE_FILE för att flytta data. Se "Windows Internals 7", "Part II," s. 644 ff för ytterligare detaljer. Det resulterande beteendet innebär en borttagningsåtgärd under huven. Tyvärr, om disabledeletenotify is "1", den retrim kommandot fortfarande lyckas. Det leder inte till unmaps. – Herr talman,

Därför måste sekvensen för att frigöra lagringen innehålla ett steg för att aktivera TRIM innan defragmenteringen körs.

2.

Om du har inaktiverat TRIM Aktivera det på systemet globalt, defragmentera och inaktivera det sedan igen, inaktiveringsprocessen kan kollidera med ofullständig körning av retrim-kommandot, även om kommandot har återgått till prompten. När vi labbtestade detta på Windows 2019 upptäckte vi att vi var tvungna att vänta i ett par sekunder innan vi ställde in disabledeletenotify till "1" igen. Vi tror att detta är ett resultat av ett samspel mellan defrag och Optimizer-tjänsten i bakgrunden.

3.

Om du schemalägger TRIM med hjälp av Enhetsoptimeraren kräver standardmenyn i Utforskaren en schemalagd aktivitet med namnet "ScheduledDefrag" (/Microsoft/Windows/Defrag) i Schemaläggaren. Om du ändrar uppgiften upptäcker enhetsoptimeraren detta och frågar om du vill återställa standardinställningarna innan du kan fortsätta. Om du inaktiverar aktiviteten kan du fortfarande köra defragmenteringskommandona manuellt, men du kan inte schemalägga dem.

4.

Detta "ScheduledDefrag" kallas även i Systemunderhåll (Control Panel\All Control Panel Items\Security and Maintenance\Automatic Maintenance).

5.

Om du inaktiverar TRIM, den UNMAP kommandoflödet till de lägre lagren i IO-stacken stoppas omedelbart. Det är förväntat beteende. Om du med tiden observerar att skillnaden mellan allokerat utrymme och använt utrymme blir för stor, kan du antingen (1) behöva ge TRIM/UNMAP kommandoflödet från den glesa filen som bearbetar mer tid, eller (2) kör åtgärden oftare.

Lösning

Därför rekommenderar vi att du lämnar dessa systemstandardinställningar och uppgifter som de är och i stället överväger att skapa en ny uppgift i schemaläggaren, som:

1. Gör TRIM ("fsutil behavior set disabledeletenotify 0")
2. Körs defrag /l against all drives ("defrag /C /L")
3. Väntar tills de resulterande kommandona skickas till matrisen ("timeout /t 60")
4. Inaktiverar TRIM again ("fsutil behavior set disabledeletenotify 1")

OBS!

Timeout-värdet i steg 3 är en interpolering av labbtester. Använd detta som utgångspunkt. Om du upptäcker att avvikelser mellan de allokerade kapacitetsvärdena på disksystemsidan och det rapporterade filsystemets använda kapacitetsvärden byggs upp, kan du behöva använda större värden, till exempel 300 sekunder (5 minuter) och ännu mer (3600; 1 timme). Du kan också behöva köra uppgiften oftare. dvs dagligen istället för veckovis. Anledningen till att dessa skillnader kan byggas upp förklaras i begränsningar (5) ovan.
 

XML-uppgiftsmall

I det följande tillhandahåller vi en mall som du kan importera till en schemaläggare som du kan använda som grund. Kopiera och klistra in xml-koden nedan i en fil, placera filen inom räckhåll för det serversystem som du vill konfigurera och använd åtgärden för uppgiftsimport för att importera uppgiften. Uppgiftsmallen nedan kallas DellSanDiskMaintenance. Den kör ovanstående fyra steg varje vecka, på en lördag kl. 20:00 (8), och placeras i roten på schemaläggaren, till exempel:

<?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>