Windows'da TRIM Devre Dışı Olduğunda İnce Diskler için Disk Bakımı Planlama

Genel Bakış

Bir Windows ortamında, büyük veri kümelerini sık sık siliyor ve yeniden oluşturuyorsanız (örneğin: Back up to disk), önceki bir silme eylemi yüksek sayıda UNMAP dizideki komutlar. Aynı disk alanını yeniden yazarsanız yazma performansınız düşebilir, çünkü gelen yazmalar UNMAPs işlenecek. UNMAPs Disk alanı öğelerini dizi tarafındaki disk havuzuna geri döndürür.

Bu depolama verimliliği mantığını yönlendiren işletim sistemi mekanizmasına "TRIM " çıktısıdır. Eğer TRIM etkindir ve dosya sistemindeki bir bloğu silerseniz dosya sistemi (NTFS) boş alan hakkında meta veriler oluşturur ve bunu G/Ç yığınına iletir. G/Ç yığınındaki disk düzeyinde, hedef diskin ATA'ya bağlı olup olmadığına karar verilir. Bu durumda bir ATA TRIM Komut fiziksel disk nesnesine gönderilir. Disk bir SCSI diskiyse, TRIM bir SCSI UNMAP.

Aynı veri bölümünü silip yeniden yazarsanız bu havuza dönüş mekanizmasının depolama verimliliği yönü sınırlıdır. Bu koşullar altında, devre dışı bırakmayı seçmiş olabilirsiniz. TRIM ilgili üretim işi süresince NTFS düzeyinde veya devre dışı bırakma TRIM tamamen ve herhangi bir bloğu farklı bir zamanda manuel olarak geri alın.

Ortaya çıkan soru şudur: Disklerin uzun vadede hala alan açısından verimli olduğundan nasıl emin olabilirsiniz?

Sınırlamalar

Lütfen bir çözüm oluşturmadan önce dikkate alınması gereken bazı sınırlamalar olduğunu unutmayın.

1.

Bir aygıtta yeniden kırpmayı tetiklemek için genellikle /L seçeneğiyle birleştirme komutunu çalıştırırsınız. TRIM özelliğini kullanarak devre dışı bıraktığınızda "fsutil behavior set disabledeletenotify 1," Kırpma veya eşlemeyi kaldırmanın yalnızca silme sırasında devre dışı bırakıldığı ve yeniden kırpmanın beklendiği gibi çalıştığı izlenimine kapılabilirsiniz. Durum bu değil. Birleştirmedeki yeniden kırpma eylemi, boş bir seyrek dosya ayıran ve ardından çağıran bir mekanizmadır. FSCTL_MOVE_FILE tıklayarak verileri taşıyın. Daha fazla ayrıntı için "Windows Internals 7", "Part II", s. 644 vd'ye bakın. Ortaya çıkan davranış, kaputun altında bir silme eylemi anlamına gelir. Ne yazık ki, eğer disabledeletenotify is "1," retrim Komut yine de başarılı. Bu, şu sonuca yol açmaz: unmaps'dir.

Sonuç olarak, depolamayı geri kazanma sırası, etkinleştirmek için bir adım içermelidir TRIM birleştirme çalıştırılmadan önce.

2.

Ayrıca, devre dışı bıraktıysanız TRIM Sistemde küresel olarak, etkinleştirin, birleştirin ve ardından tekrar devre dışı bırakın, devre dışı bırakma işlemi, komut istemine geri dönmüş olmasına rağmen, tamamlanmamış yeniden kırpma komutunun yürütülmesiyle çakışabilir. Bunu Windows 2019'da laboratuvarda test ederken, ayarlamadan önce birkaç saniye beklememiz gerektiğini gördük disabledeletenotify tekrar "1"e. Bunun, aralarındaki etkileşimin bir sonucu olduğuna inanıyoruz. defrag komut ve arka planda Optimizer hizmeti.

3.

Zamanlama TRIM Drive Optimizer'ı kullanarak, varsayılan Explorer menüsü, varsayılan olarak adlandırılan zamanlanmış bir görev gerektirir. "ScheduledDefrag" (/Microsoft/Windows/Defrag) Görev Zamanlayıcı'da. Görevi değiştirirseniz, Drive Optimizer bu durumu algılar ve devam etmeden önce varsayılanları geri yüklemenizi ister. Görevi devre dışı bırakırsanız, birleştirme komutlarını manuel olarak çalıştırmaya devam edebilirsiniz, ancak bunları zamanlayamazsınız.

4.

Bu "ScheduledDefrag" görevi Sistem Bakımında da adlandırılır (Control Panel\All Control Panel Items\Security and Maintenance\Automatic Maintenance).

5.

Devre dışı bırakırsanız TRIM, bu UNMAP GÇ yığınının alt katmanlarına komut akışı hemen durur. Bu beklenen bir davranıştır. Zaman içinde, ayrılan alan ile kullanılan alan arasındaki farkın çok büyüdüğünü gözlemlerseniz, (1) TRIM/UNMAP Komut akışı seyrek dosyadan daha fazla zaman işleme veya (2) müdahaleyi daha sık çalıştırma.

Çözüm

Sonuç olarak, bu sistem varsayılan ayarlarını ve görevlerini olduğu gibi bırakmanızı ve bunun yerine görev zamanlayıcıda yeni bir görev oluşturmayı düşünmenizi öneririz:

1. Sağ -lar TRIM ("fsutil behavior set disabledeletenotify 0")
2. Çalışır defrag /l against all drives ("defrag /C /L")
3. Ortaya çıkan komutlar diziye gönderilene kadar bekler ("timeout /t 60")
4. Devre dışı bırakır TRIM again ("fsutil behavior set disabledeletenotify 1")

NOT

3. adımdaki zaman aşımı değeri, laboratuvar testlerinin enterpolasyonudur. Bunu bir başlangıç noktası olarak kullanın. Dizi tarafında ayrılan kapasite değerleri ile dosya sistemi tarafından bildirilen kullanılan kapasite değerleri arasında tutarsızlıklar oluştuğunu fark ederseniz 300 saniye (5 dakika) ve daha fazla (3600; 1 saat) gibi daha büyük değerler kullanmanız gerekebilir. Alternatif olarak, görevi daha sık çalıştırmanız gerekebilir; yani haftalık yerine günlük. Bu tutarsızlıkların oluşmasının nedeni yukarıdaki Sınırlamalar (5)'te açıklanmıştır.
 

XML Görev Şablonu

Aşağıda, temel olarak kullanmanız için bir görev zamanlayıcıya aktarabileceğiniz bir şablon sunuyoruz. Aşağıdaki xml kodunu kopyalayıp bir dosyaya yapıştırın, dosyayı yapılandırmak istediğiniz sunucu sisteminin erişebileceği bir yere yerleştirin ve görevi içe aktarmak için görev içe aktarma eylemini kullanın. Aşağıdaki görev şablonunun adı verilir DellSanDiskMaintenance. Yukarıdaki dört adımı haftada bir, Cumartesi günü saat 20:00'de (20:00) çalıştırır ve zamanlayıcının köküne yerleştirilir, örneğin:

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