Aracılığıyla paylaş

512 bayt Öykünme (512e) Disk Uyumluluğu Güncelleştirmesi

Peron

İstemcileri - Windows Vista, Windows 7, Windows 7 SP1
Sunucuları - Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 SP1

Özellik Etkisi

Önem Derecesi - Yüksek
Sıklık - Yüksek

Açıklama

Areal yoğunluklar her geçen yıl artmaktadır ve son 3 TB diskin ortaya çıkmasıyla birlikte, azalan SinyaldenNoise-Ratio (SNR) ile başa çıkmak için kullanılan hata düzeltme mekanizmaları alan verimsiz hale gelmektedir; yani, medyanın kullanılabilir olduğundan emin olmak için artan ek yük miktarı gerekir. Bu hata düzeltme mekanizmasını geliştirmeye yönelik depolama sektörü çözümlerinden biri, daha büyük bir fiziksel kesim boyutu içeren farklı bir fiziksel medya biçimi tanıtmaktır. Bu yeni fiziksel medya biçimi Gelişmiş Biçimolarak adlandırılır. Bu nedenle, modern depolama cihazlarının sektör boyutuyla ilgili varsayımlarda bulunmak artık güvenli değildir ve geliştiricilerin bir etki olup olmadığını belirlemek için kodlarını temel alan varsayımları incelemesi gerekir.

Bu konu başlığında, Gelişmiş Biçimli depolama cihazlarının yazılım üzerindeki etkisi tanıtılır, bu tür medyayı desteklemeye yardımcı olmak için hangi uygulamaların yapabilecekleri açıklanır ve geliştiricilerin bu tür cihazları desteklemesini sağlayacak altyapı ele alınmaktadır. Bu konuda sunulan malzeme Gelişmiş Biçim diskleriyle uyumluluğu geliştirmeye yönelik yönergeler sağlasa da, bilgiler genellikle Gelişmiş Biçim disklerine sahip tüm sistemler için geçerlidir. Aşağıdaki Windows sürümleri, fiziksel kesim boyutunu sorgulama desteği sağlar:

  • Microsoft KB 982018 ile Windows 7
  • Windows 7 SP1
  • Microsoft KB 982018 ile Windows Server 2008 R2
  • Windows Server 2008 R2 SP1
  • Microsoft KB 2553708 ile Windows Vista
  • Microsoft KB 2553708 ile Windows Server 2008

Ek ayrıntılar için bkz. Windows'da büyük kesimli sürücüler için Microsoft destek ilkesi hakkında bilgi.

Gelişmiş Biçim diskleri hakkında daha fazla bilgi için lütfen depolama satıcınıza başvurun.

Mantıksal ve Fiziksel Kesim Boyutu karşılaştırması

Medya biçimindeki bu değişikliğin tanıtılmasındaki endişelerden biri, bugün piyasada mevcut olan yazılım ve donanımla uyumluluk. Geçici bir çözüm olarak, depolama sektörü başlangıçta normal bir 512 baytlık kesim diskine öykünen ancak standart ATA ve SCSI komutları aracılığıyla gerçek kesim boyutu hakkında bilgi sağlayan diskleri kullanıma sunar. Bu öykünme sonucunda iki kesim boyutu vardır:

  • Mantıksal Kesim: Medya için mantıksal blok adresleme için kullanılan birim. Bunu depolamanın kabul edebildiği en küçük yazma birimi olarak da düşünebiliriz. Bu öykünme.

  • Fiziksel Kesim: Cihaza yönelik okuma ve yazma işlemlerinin tek bir işlemle tamamlandığı birim. Bu, atomik yazma birimidir.

IOCTL_DISK_GET_DRIVE_GEOMETRY gibi geçerli Windows API'lerinin çoğu mantıksal kesim boyutunu döndürür, ancak fiziksel kesim boyutu, STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR yapısındaki bytesperphysicalSector alanında yer alan ilgili bilgilerle IOCTL_STORAGE_QUERY_PROPERTY denetim kodu aracılığıyla alınabilir. Bu, makalenin devamında daha ayrıntılı olarak ele alınmalıdır.

Büyük Kesim Medyasının İlk Türleri

Depolama sektörü, 4 KB fiziksel kesim boyutuna sahip medyalar için bu yeni Gelişmiş Biçim depolama türüne geçiş yapmak için hızla çaba harcamaktadır. İki tür medya piyasaya sürülecek:

  • 4 KB Yerel: Bu medya öykünme katmanına sahip değildir ve mantıksal ve fiziksel kesim boyutu olarak doğrudan 4 KB'yi kullanıma sunar. Bu medya şu anda Windows ve diğer işletim sistemlerinin çoğu tarafından desteklenmiyor. Ancak Microsoft, windows'un gelecek bir sürümünde bu tür medyayı desteklemenin fizibilitesi hakkında bir araştırma yürütmektedir ve uygun olduğunda bir Bilgi Bankası makalesi yayımlayacaktır.
  • 512 bayt Öykünme (512e): Bu medya, önceki bölümde açıklandığı gibi bir öykünme katmanına sahiptir ve mantıksal kesim boyutu olarak 512 bayt gösterir (bugünkü normal diske benzer), ancak fiziksel kesim boyutu bilgilerini (4 KB) kullanılabilir hale getirir. Şu anda birkaç depolama satıcısının pazara tanıtmaya devam eden özelliği budur. Bu yeni medya türüyle ilgili genel sorun, uygulama ve işletim sistemlerinin çoğunluğunun fiziksel kesim boyutunun varlığını anlamamasıdır ve bu da aşağıda ele alınacağı gibi bir dizi soruna neden olabilir.

Öykünme Nasıl Çalışır: Okuma-Modify-Write (RMW)

Depolama ortamı, fiziksel ortamın değiştirilebildiği belirli bir birime sahiptir. Diğer bir ifadeyle, medya yalnızca fiziksel kesim boyutundaki birimler halinde yazılabilir veya yeniden yazılabilir. Bu nedenle, bu birim düzeyinde gerçekleştirilmeyen yazma işlemleri için ek adımlar gerekir. Bu adımları aşağıdaki örnekte inceleyeceğiz.

Bu senaryoda, bir uygulamanın 512 baytlık bir mantıksal kesimde bulunan bir Datastor kaydının içeriğini güncelleştirmesi gerekir. Aşağıdaki diyagramda depolama cihazının yazma işlemini tamamlaması için gereken adımlar gösterilmektedir:

512 baytlık mantıksal kesim içindeki veri deposu kaydını yükseltmek için gereken adımlar

Yukarıda gösterildiği gibi bu işlem, depolama cihazının performans kaybına neden olabilecek bazı çalışmalarını içerir. Bu ek çalışmayı önlemek için uygulamaların aşağıdakileri yapacak şekilde güncelleştirilmesi gerekir:

  • Fiziksel kesim boyutu için sorgu.
  • Yazmaların bildirilen fiziksel kesim boyutuna hizalandığından emin olun.

Okuma-Modify-Write Dayanıklılık Etkisi

Dayanıklılık, bir uygulamanın oturumlar arasındaki durumu kurtarma özelliğinden bahseder. 512e depolama cihazının 512 baytlık kesim yazma (Okuma-Modify-Write döngüsü) gerçekleştirmesi için nelerin gerekli olduğunu gördük. Medyada önceki fiziksel kesimin üzerine yazma işlemi kesintiye uğrarsa neler olacağına bakalım. Sonuçları ne olur?

  • Sabit disk sürücülerinin çoğu yerinde güncelleştirildiğinden, fiziksel kesim (fiziksel kesimin bulunduğu medya bölümü) kısmi bir üzerine yazma nedeniyle eksik bilgilerle bozulmuş olabilir. Başka bir ifadeyle, bunu 8 mantıksal kesimin tümünü (fiziksel kesimin mantıksal olarak içerdiği) kaybetmiş olabileceğini düşünebilirsiniz.

  • Veri deposuna sahip uygulamaların çoğu medya hatalarından, sekiz kesimin kaybından veya başka bir yolla sekiz işleme kaydının kaybedilmesi veri deposunun düzgün bir şekilde kurtarılmasını imkansız hale getirme özelliğiyle tasarlanmıştır. Bir yöneticinin veritabanını bir yedekten el ile geri yüklemesi veya hatta uzun bir yeniden derleme gerçekleştirmesi gerekebilir.

  • Bir diğer önemli etki, başka bir uygulamanın OkumaModify-Write döngüsüne neden olması, uygulamanız çalışmasa bile verilerinizin kaybolmasına neden olabilir! Bunun nedeni, verilerinizin ve diğer uygulamanın verilerinin aynı fiziksel kesimde bulunabileceğidir.

Bunu göz önünde bulundurarak, uygulama yazılımının kodda alınan varsayımları yeniden değerlendirmesi ve bu makalenin devamında ele alınan bazı ilginç müşteri senaryolarıyla birlikte mantıksal-fiziksel kesim boyutu ayrımının farkında olması önemlidir.

Uygulamanız bir günlük yapısı veri deposu kullanıyorsa bu sorunun oluşma olasılığı daha yüksektir.

Okumadan Kaçınma-Modify-Write

Bazı depolama satıcıları, Okuma-Modify-Write döngüsünün performans ve dayanıklılık sorunlarını hafifletmeye yardımcı olmak için belirli 512e depolama cihazlarında bazı risk azaltma düzeylerini kullanıma sunarken, iş yükü açısından herhangi bir azaltmanın üstesinden gelebileceği kadar çok şey vardır. Bu nedenle, uygulamalar uzun vadeli bir çözüm olarak bu azaltmaya güvenmemelidir.

Bunun çözümü, sürücü içi risk azaltma değildir, ancak uygulamaların Okuma-Modify-Write döngüsünü önlemek için doğru işleri yapmalarını sağlamaktır. Bu bölümde, uygulamaların büyük kesim diskleriyle ilgili sorunlarla karşılaşabileceği yaygın senaryolar ele alınmaktadır ve her sorunu çözmek için bir araştırma yolu önermektedir.

Sorun 1: Bölüm fiziksel kesim sınırına hizalanmamış

Yönetici/kullanıcı diski bölümlediğinde, ilk bölüm hizalanmış bir sınırda oluşturulmamış olabilir. Bu, sonraki tüm yazmaların fiziksel kesim sınırlarına hizalanmamış olmasına neden olabilir. Windows Vista SP1 ve Windows Server 2008'den itibaren ilk bölüm, diskin ilk 1024 KB'lık bölümüne yerleştirilir (4 GB veya daha büyük diskler için, aksi takdirde hizalama 64 KB'tır) 4 KB fiziksel kesim sınırına hizalanır. Ancak, Windows XP'de varsayılan bölümleme, üçüncü taraf bölümleme yardımcı programı veya Windows API'lerinin yanlış kullanımı göz önüne alındığında, oluşturulan bölümler fiziksel kesim sınırına hizalanmayabilir. Geliştiricilerin, hizalamayı sağlamaya yardımcı olmak için doğru API'lerin kullanıldığından emin olması gerekir. Bölüm hizalamasının aşağıda özetlenmiş olduğundan emin olmak için önerilen API'ler.

IVdsPack::CreateVolume ve IVdsPack2::CreateVolume2 API'leri yeni birim oluşturulduğunda belirtilen hizalama parametresini kullanmaz ve bunun yerine işletim sistemi için varsayılan hizalama değerini kullanır (Windows Vista SP1 öncesi 63 bayt kullanır ve Windows Vista SP1 sonrası yukarıda belirtilen varsayılan değerleri kullanır). Bu nedenle, bölüm oluşturması gereken uygulamaların, belirtilen hizalama parametresini kullanan IVdsCreatePartitionEx::CreatePartitionEx veya IVdsAdvancedDisk::CreatePartition API'lerini kullanması önerilir.

Hizalamanın doğru olduğundan emin olmak için en iyi yol, bölümü oluştururken doğru şekilde yapmaktır. Aksi takdirde uygulamanızın yazma işlemleri yaparken veya başlatma sırasında hizalamayı dikkate alması gerekir; bu çok karmaşık bir konu olabilir. Windows Vista SP1 itibarıyla bu genellikle bir sorun değildir; ancak, Windows'un eski sürümleri bazı Gelişmiş Biçim disklerinde performans sorunlarına yol açabilecek hizalanmamış bölümler oluşturabilir.

Sorun 2: Fiziksel Kesim Boyutuna hizalanmamış eklenmemiş Yazma işlemleri

Temel sorun, çıkarılmamış yazmaların depolama medyasının bildirilen fiziksel kesim boyutuna hizalanmamasıdır ve bu da sürücüde performans sorunlarına neden olabilecek okumaModify-Write tetikler. Öte yandan arabelleğe alınan yazma işlemleri sayfa boyutuna (4 KB) hizalanır ve bu da büyük kesim medyasının ilk neslinin fiziksel kesim boyutudur. Bununla birlikte, veri deposu olan çoğu uygulama kaldırılmamış yazma işlemleri gerçekleştirir ve bu nedenle bu yazma işlemlerinin fiziksel kesim boyutundaki birimler halinde gerçekleştirildiğinden emin olması gerekir.

Uygulamanızın kasalanmamış G/Ç sorunlarını belirlemeye yardımcı olmak için, CreateFile işlevini çağırırken dwFlagsAndAttributes parametresine FILE_FLAG_NO_BUFFERING bayrağını eklediğinizden emin olun.

Ayrıca, şu anda yazmaları kesim boyutuna hizalarsanız, medyanın kesim boyutunu sorgulayan mevcut API'lerin çoğu yalnızca adresleme birimini( yani mantıksal kesim boyutunu) sorguladıkça, bu kesim boyutu büyük olasılıkla yalnızca mantıksal kesim boyutudur. Buradaki ilginin sektör boyutu, gerçek bölünmezlik birimi olan fiziksel kesim boyutudur. Mantıksal kesim boyutunu alan API'lerin bazı örnekleri şunlardır:

  • GetDiskFreeSpace , GetDiskFreeSpaceEx
  • FileFsVolumeInformation
  • IOCTL_DISK_GET_DRIVE_GEOMETRY, IOCTL_DISK_GET_DRIVE_GEOMETRY_EX
  • IVdsDisk::GetProperties, IVdsDisk3::GetProperties2

Fiziksel Kesim Boyutu Için Sorgulama

Bir uygulamanın birimin fiziksel kesim boyutunu nasıl sorgulayabileceğinizi gösteren bir kod örneği için bkz. https://msdn.microsoft.com/library/ff800831.aspx.

Yukarıdaki kod örneği birimin fiziksel kesim boyutunu almanıza olanak sağlarken, bazı sürücülerin doğru biçimlendirilmiş veriler döndüremediğini gözlemlediğinden, bunu kullanmadan önce bildirilen fiziksel kesim boyutu üzerinde bazı temel akıl sağlığı denetimi yapmanız gerekir:

  • Bildirilen fiziksel kesim boyutunun >= bildirilen mantıksal kesim boyutu olduğundan emin olun. Değilse, uygulamanız bildirilen mantıksal kesim boyutuna eşit bir fiziksel kesim boyutu kullanmalıdır.
  • Bildirilen fiziksel kesim boyutunun iki güçte olduğundan emin olun. Değilse, uygulamanız bildirilen mantıksal kesim boyutuna eşit bir fiziksel kesim boyutu kullanmalıdır.
  • Fiziksel kesim boyutu 512 bayt ile 4 KB arasında iki güç değeriyse, bildirilen mantıksal kesim boyutuna yuvarlanmış bir fiziksel kesim boyutu kullanmayı düşünmelisiniz.
  • Fiziksel kesim boyutu 4 KB'tan büyük iki güç değeriyse, bu değeri kullanmadan önce uygulamanızın bu senaryoyu işleme becerisini değerlendirmeniz gerekir. Aksi takdirde, 4 KB'a yuvarlanmış bir fiziksel kesim boyutu kullanmayı düşünmelisiniz.

Fiziksel kesim boyutunu almak için bu IOCTL'yi kullanmanın çeşitli sınırlamaları vardır:

  • Yükseltilmiş ayrıcalık gerektirir. Uygulamanız ayrıcalıkla çalışmıyorsa, yukarıda belirtildiği gibi bir Windows Hizmet Uygulaması yazmanız gerekebilir.

  • SMB birimlerini desteklemez. Bu birimlerde fiziksel kesim boyutu sorgulamasını desteklemek için bir Windows Hizmet Uygulaması da yazmanız gerekebilir.

  • Herhangi bir dosya tanıtıcısına verilemez (IOCTL bir Birim Tanıtıcısına verilmelidir).

  • Yalnızca bu makalenin başında listelenen Windows sürümlerinde desteklenir.

İşleme kayıtları 512 baytlık kesimlere doldurulur

Veri deposu olan uygulamalar genellikle meta veri değişiklikleriyle ilgili bilgileri koruyan veya veri deposunun yapısını koruyan bir tür işleme kaydına sahiptir. Bir kesimin kaybının birden çok kaydı etkilemediğinden emin olmak için, bu işleme kaydı genellikle bir kesim boyutuna doldurulur. Fiziksel kesim boyutu daha büyük olan bir diskte, uygulamanın önceki bölümde gösterildiği gibi fiziksel kesim boyutunu sorgulaması ve her işleme kaydının bu boyuta ayarlandığından emin olması gerekir. Bu yalnızca Okuma-Modify-Write döngüsünden kaçınmaz, fiziksel bir kesimin kaybolması durumunda yalnızca bir İşleme Kaydının kaybedileceğinden emin olmanıza yardımcı olur.

Günlük dosyaları hizalanmamış öbekler halinde yazılır

Dosyalanmamış G/Ç genellikle bir günlük dosyası güncelleştirilirken veya eklenirken kullanılır. Bu güncelleştirmelerin doğru hizalandığından emin olmanın birkaç yolu vardır:

  • Günlük güncelleştirmelerini işletim medyasının bildirilen fiziksel kesim boyutuna dahili olarak arabelleğe alma ve sorun günlüğü yazma işlemleri yalnızca fiziksel kesim birimi dolu olduğunda
  • Arabelleğe alınan G/Ç kullanma

Sorun 3: 512 baytlık Kesimleri kullanan Dosya Biçimleri

Standart dosya biçimlerine (VHD 1.0 gibi) sahip bazı uygulamalarda bu dosyalar 512 baytlık kesim boyutu varsaymak üzere sabit kodlanmış olabilir. Bu nedenle, bu dosyaya yapılan güncelleştirmeler ve yazma işlemleri cihazda OkumaModify-Write döngüsüne neden olur ve bu da potansiyel olarak müşterileriniz için performans ve dayanıklılık sorunlarına neden olur. Ancak, bir uygulamanın bu tür medya üzerinde çalışma desteği sağlamanın yolları vardır, örneğin:

  • Yazmaların fiziksel kesim boyutundaki birimler halinde gerçekleştirildiğinden emin olmak için arabelleğe almayı kullanın
  • Güncelleştirmelerin bildirilen fiziksel kesim boyutundaki birimler halinde gerçekleştirilmesini sağlamaya yardımcı olabilecek bir iç OkumaModify-Write uygulama
  • Mümkünse pad, doldurmanın boş alan olarak yorumlanması amacıyla fiziksel bir kesime kayıt yapar
  • Daha büyük kesimler için destekle uygulama veri yapısının yeni bir sürümünü yeniden tasarlamayı göz önünde bulundurun

Sorun 4: Bildirilen Fiziksel Kesim boyutu oturumlar arasında değişebilir

Datastor'ın barındırıldığı temel depolamanın bildirilen fiziksel kesim boyutunun değişebileceği birçok senaryo vardır. Bunlardan en yaygın olanı, Datastor'ı başka bir birime, hatta ağ üzerinden geçirmenizdir. Bildirilen fiziksel kesim boyutundaki bir değişiklik birçok uygulama için beklenmeyen bir olay olabilir ve bazı uygulamaların yeniden başlatılamamasına bile neden olabilir.

Bu, desteklenmek için en kolay senaryo değildir ve burada bir danışmanlık olarak belirtilmektedir. Müşterilerinizin mobilite gereksinimlerini göz önünde bulundurmalı ve 512e medyası kullanılarak müşterilerin olumsuz etkilenmediğinden emin olmak için desteğinizi buna göre ayarlamanız gerekir.

4 KB Yerel Medya

512 bayt öykünme medyası, 512 bayt yerel ve 4 KB yerel medya arasında geçiş adımı olarak ifade edilir ve 512e kullanıma sunulduktan hemen sonra 4 KB yerel medyanın yayınlanmasını bekliyoruz. Bu medyanın dikkate alınması gereken birkaç önemli etkisi vardır:

  • Mantıksal ve fiziksel kesim boyutları 4 KB'tır
  • Öykünme katmanı olmadığından, hizalanmamış yazma işlemleri depolama tarafından başarısız olur
  • Gizli dayanıklılık isabeti yok – uygulamalar çalışır veya çalışmaz

Microsoft şu anda Windows'un gelecek bir sürümünde bu tür medyalar için destek araştırsa da ve uygun olduğunda bir KB makalesi yayımlayacak olsa da, uygulama geliştiricilerin bu tür medyalar için önceden destek sağlamayı göz önünde bulundurması gerekir.

Kapanış

Bu makalede, büyük sektör medyasının birçok yaygın dağıtım senaryosuna neden olan etkileri ele aldık. Okuma-Değiştirme-Yazma'nın performansını ve dayanıklılığını, bu medyanın getirebileceği bazı ilginç senaryoları ve yazılımla ilgili neden olabilecek sorunlar kümesini gördük. Bu da son kullanıcıyı etkiler. Depolama sektörü hızla daha büyük sektör boyutlarına sahip medyaya geçiş yapmakta ve çok yakında müşteriler geleneksel 512 baytlık kesim boyutlarına sahip diskler satın alamayacaktır.

Bu, canlı bir belgedir ve geliştiricilerin bu geçişi anlamasına yardımcı olması için bir yardım olarak amaçlanır. Büyük sektör geçişi ve sizin için önemli olan senaryoları nasıl etkilediği hakkında konuşmak için ilgili kuruluşlarınızla, müşterilerle, BT Uzmanlarıyla ve donanım satıcılarınızla bir konuşma başlatmanız gerekir.