Udostępnij za pośrednictwem

Aktualizacja zgodności dysków 512-bajtowych emulacji (512e)

  • Artykuł

Podest

Klienci — Windows Vista, Windows 7, Windows 7 z dodatkiem SP1
Servers — Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 z dodatkiem SP1

Wpływ funkcji

ważność — wysoka
częstotliwość — wysoka

Opis

Gęstość areal rośnie co rok, a wraz z niedawnym pojawieniem się 3 TB dysków, mechanizmy korekty błędów używane do radzenia sobie z malejącym sygnałem doNoise-Ratio (SNR) stają się nieefektywne miejsca - czyli zwiększenie nakładu pracy jest wymagane w celu zapewnienia, że nośnik jest użyteczny. Jednym z rozwiązań w branży magazynowania w celu poprawy tego mechanizmu korekty błędów jest wprowadzenie innego formatu nośnika fizycznego, który obejmuje większy rozmiar sektora fizycznego. Ten nowy format nośnika fizycznego nosi nazwę Advanced Format. W związku z tym nie można już bezpiecznie założyć żadnych założeń dotyczących wielkości sektora nowoczesnych urządzeń magazynujących, a deweloperzy będą musieli zbadać założenia dotyczące ich kodu, aby ustalić, czy ma to wpływ.

W tym temacie przedstawiono wpływ urządzeń magazynujących w formacie zaawansowanym na oprogramowanie, omówiono, jakie aplikacje mogą zrobić, aby ułatwić obsługę tego typu multimediów, oraz omówiono infrastrukturę umożliwiającą deweloperom obsługę tych typów urządzeń. Chociaż materiał przedstawiony w tym temacie zawiera wskazówki dotyczące poprawy zgodności z dyskami w formacie zaawansowanym, informacje dotyczą ogólnie wszystkich systemów z dyskami w formacie zaawansowanym. Następujące wersje systemu Windows zapewniają obsługę wykonywania zapytań dotyczących rozmiaru sektora fizycznego:

  • System Windows 7 z 982018 bazy wiedzy firmy Microsoft
  • Windows 7 SP1
  • Windows Server 2008 R2 z 982018 bazy wiedzy firmy Microsoft
  • Windows Server 2008 R2 SP1
  • Windows Vista z 2553708 bazy wiedzy firmy Microsoft
  • Windows Server 2008 z 2553708 bazy wiedzy firmy Microsoft

Aby uzyskać dodatkowe informacje, zobacz Informacje o zasadach pomocy technicznej firmy Microsoft dla dysków z dużymi sektorami w systemie Windows.

Aby uzyskać więcej informacji na temat dysków w formacie zaawansowanym, skontaktuj się z dostawcą magazynu.

Rozmiar sektora logicznego a fizycznego

Jedną z obaw związanych z wprowadzeniem tej zmiany w formacie nośnika jest zgodność z oprogramowaniem i sprzętem dostępnym obecnie na rynku. Jako tymczasowe rozwiązanie branża magazynowania początkowo wprowadza dyski emulujące zwykły dysk sektora 512 bajtów, ale udostępnia informacje o prawdziwym rozmiarze sektora za pomocą standardowych poleceń ATA i SCSI. W wyniku tej emulacji istnieją dwa rozmiary sektorów:

  • sektora logicznego: jednostka używana do adresowania bloków logicznych dla nośnika. Możemy również traktować ją jako najmniejszą jednostkę zapisu, którą magazyn może zaakceptować. Jest to emulacja.

  • sektora fizycznego: jednostka, dla której operacje odczytu i zapisu na urządzeniu są wykonywane w ramach jednej operacji. Jest to jednostka niepodzielnego zapisu.

Większość bieżących interfejsów API systemu Windows, takich jak IOCTL_DISK_GET_DRIVE_GEOMETRY, zwróci rozmiar sektora logicznego, ale rozmiar sektora fizycznego można pobrać za pomocą kodu sterującego IOCTL_STORAGE_QUERY_PROPERTY z odpowiednimi informacjami zawartymi w BytesPerPhysicalSector w strukturze STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR. Omówiono to bardziej szczegółowo w dalszej części artykułu.

Początkowe typy dużych mediów sektora

Branża magazynowania szybko zwiększa wysiłki na rzecz przejścia na ten nowy typ magazynu w formacie zaawansowanym dla nośników o rozmiarach sektora fizycznego o rozmiarach 4 KB. Dwa rodzaje mediów zostaną wydane na rynek:

  • 4 KB Natywna: ten nośnik nie ma warstwy emulacji i bezpośrednio uwidacznia 4 KB jako rozmiar sektora logicznego i fizycznego. Ten nośnik nie jest obecnie obsługiwany przez system Windows i większość innych systemów operacyjnych. Jednak firma Microsoft przeprowadza dochodzenie w sprawie możliwości obsługi tego typu multimediów w przyszłej wersji systemu Windows i wyda artykuł z bazy wiedzy, jeśli jest to konieczne.
  • emulacji 512 bajtów (512e): ten nośnik ma warstwę emulacji, jak opisano w poprzedniej sekcji i uwidacznia 512 bajtów jako rozmiar sektora logicznego (podobny do zwykłego dysku dzisiaj), ale udostępnia informacje o rozmiarze sektora fizycznego (4 KB). To właśnie kilku dostawców magazynu wprowadza obecnie na rynek. Ten ogólny problem z tym nowym typem nośnika polega na tym, że większość aplikacji i systemów operacyjnych nie rozumie istnienia rozmiaru sektora fizycznego, co może spowodować szereg problemów, które zostaną omówione poniżej.

Jak działa emulacja: odczyt-Modify-Write (RMW)

Nośnik magazynu ma określoną jednostkę, w ramach której można zmodyfikować nośnik fizyczny. Oznacza to, że nośniki można zapisywać lub zapisywać tylko w jednostkach rozmiaru sektora fizycznego. W związku z tym zapisy, które nie są wykonywane na tym poziomie lekcji, wymagają dodatkowych kroków, które omówimy w poniższym przykładzie.

W tym scenariuszu aplikacja musi zaktualizować zawartość rekordu datastor znajdującego się w sektorze logicznym 512 bajtów. Na poniższym diagramie przedstawiono kroki niezbędne do ukończenia zapisu przez urządzenie magazynujące:

kroki wymagane do uaktualnienia rekordu obiektu datastor w 512-bajtowego sektora logicznego

Jak pokazano powyżej, ten proces obejmuje pewną pracę przez urządzenie magazynujące, które może spowodować utratę wydajności. Aby uniknąć tej dodatkowej pracy, aplikacje muszą zostać zaktualizowane w celu wykonania następujących czynności:

  • Wykonaj zapytanie dotyczące rozmiaru sektora fizycznego.
  • Upewnij się, że zapisy są dopasowane do zgłoszonego rozmiaru sektora fizycznego.

Wpływ odporności odczytu iModify-Write

Odporność mówi o możliwości odzyskania stanu przez aplikację między sesjami. Widzieliśmy, co jest niezbędne dla urządzenia magazynu 512e do wykonania 512-bajtowego zapisu sektora — cyklu odczyt-Modify-Write. Przyjrzyjmy się temu, co by się stało, gdyby proces zastępowania poprzedniego sektora fizycznego na nośnikach został przerwany. Jakie byłyby konsekwencje?

  • Ponieważ większość dysków twardych jest aktualizowana, sektor fizyczny — czyli część nośnika, w którym znajdował się sektor fizyczny — mogła zostać uszkodzona niekompletnymi informacjami z powodu częściowego zastąpienia. Innymi słowy, można o tym myśleć jako potencjalnie o utracie wszystkich 8 sektorów logicznych (które sektor fizyczny logicznie zawiera).

  • Podczas gdy większość aplikacji z magazynem danych jest zaprojektowana z możliwością odzyskiwania po błędach multimediów, utrata ośmiu sektorów lub innego sposobu, utrata ośmiu rekordów zatwierdzeń może potencjalnie uniemożliwić odzyskanie magazynu danych w sposób bezproblemowy. Administrator może wymagać ręcznego przywrócenia bazy danych z kopii zapasowej lub może nawet wymagać przeprowadzenia długiej ponownej kompilacji.

  • Jedną z ważniejszych kwestii jest to, że działanie innej aplikacji powodujące cykl odczyt-Modify-Write może potencjalnie spowodować utratę danych , nawet jeśli aplikacja nie jest uruchomiona! Jest to po prostu spowodowane tym, że dane i dane innych aplikacji mogą znajdować się w tym samym sektorze fizycznym.

Mając to na uwadze, ważne jest, aby oprogramowanie aplikacji ponownie uwzględniało wszelkie założenia podjęte w kodzie i uwzględniało rozróżnienie rozmiaru sektora logicznego i fizycznego wraz z ciekawymi scenariuszami klienta omówionymi w dalszej części tego artykułu.

Ten problem jest bardziej prawdopodobny, jeśli aplikacja korzysta z magazynu danych struktury dziennika.

UnikanieModify-Write odczytu

Podczas gdy niektórzy dostawcy magazynu mogą wprowadzać pewne poziomy ograniczania ryzyka na niektórych urządzeniach magazynujących 512e, aby spróbować złagodzić problemy z wydajnością i odpornością cyklu odczyt-Modify-Write, istnieje tylko tyle środków zaradczych, które mogą obsłużyć pod względem obciążenia. W związku z tym aplikacje nie powinny polegać na tym zaradczem jako długoterminowym rozwiązaniu.

Rozwiązaniem tego problemu nie jest ograniczenie ryzyka, ale aby aplikacje miały odpowiedni zestaw rzeczy, aby uniknąć cyklu odczyt-Modify-Write. W tej sekcji omówiono typowe scenariusze, w których aplikacje mogą mieć problemy z dużymi dyskami sektora i sugerują możliwość badania, aby spróbować rozwiązać każdy problem.

Problem 1: Partycja nie jest wyrównana do granicy sektora fizycznego

Gdy administrator/użytkownik partycjonuje dysk, pierwsza partycja mogła nie zostać utworzona na wyrównanej granicy. Może to spowodować, że wszystkie kolejne zapisy staną się nieprzygotowane do granic sektora fizycznego. Od systemu Windows Vista z dodatkiem SP1 i Windows Server 2008 pierwsza partycja jest umieszczana na pierwszej partycji 1024 KB dysku (w przypadku dysków 4 GB lub większych, w przeciwnym razie wyrównanie wynosi 64 KB), które jest wyrównane do granicy sektora fizycznego 4 KB. Jednak biorąc pod uwagę domyślne partycjonowanie w systemie Windows XP, narzędzie partycjonowania innej firmy lub niepoprawne użycie interfejsów API systemu Windows, utworzone partycje mogą nie być dostosowane do granicy sektora fizycznego. Deweloperzy będą musieli upewnić się, że poprawne interfejsy API są używane w celu zapewnienia wyrównania. Zalecane interfejsy API ułatwiające zapewnienie wyrównania partycji przedstawiono poniżej.

IVdsPack::CreateVolume i IVdsPack2::CreateVolume2 interfejsy API nie używają określonego parametru wyrównania podczas tworzenia nowego woluminu, a zamiast tego użyje wartości wyrównania domyślnej dla systemu operacyjnego (w wersji wcześniejszej niż Windows Vista SP1 będzie używać 63 bajtów, a post Windows Vista SP1 użyje wartości domyślnych wymienionych powyżej). Dlatego zaleca się, aby aplikacje, które muszą tworzyć partycje, używają IVdsCreatePartitionEx::CreatePartitionEx lub IVdsAdvancedDisk::CreatePartition interfejsów API, które używają określonego parametru wyrównania.

Najlepszym sposobem zapewnienia, że wyrównanie jest poprawne, jest to, aby wykonać to prawidłowo podczas początkowego tworzenia partycji. W przeciwnym razie aplikacja będzie musiała uwzględnić wyrównanie podczas wykonywania operacji zapisu lub inicjowania , co może być bardzo złożoną sprawą. Od systemu Windows Vista z dodatkiem SP1 zazwyczaj nie jest to problem; jednak starsze wersje systemu Windows mogą tworzyć nieprzygotowane partycje, które mogą potencjalnie prowadzić do problemów z wydajnością niektórych dysków w formacie zaawansowanym.

Problem 2: Niesforowane zapisy nie są wyrównane do rozmiaru sektora fizycznego

Podstawowym problemem jest to, że niebuforowane zapisy nie są dopasowane do zgłaszanego rozmiaru sektora fizycznego nośnika magazynu, co wyzwalaModify-Write odczytu na dysku, co może spowodować problemy z wydajnością. Z drugiej strony zapisy buforowane są wyrównane do rozmiaru strony — 4 KB — co przypadkowo jest rozmiarem sektora fizycznego pierwszej generacji dużych multimediów sektora. Jednak większość aplikacji z magazynem danych wykonuje niebuforowane zapisy, a tym samym musi upewnić się, że te zapisy są wykonywane w jednostkach rozmiaru sektora fizycznego.

Aby określić, czy w aplikacji występują problemy z niebuforowanym we/wy, sprawdź, czy podczas wywoływania funkcji CreateFile dołączono flagę FILE_FLAG_NO_BUFFERING w dwFlagsAndAttribut es.

Co więcej, jeśli obecnie dopasowujesz zapisy do rozmiaru sektora, ten rozmiar sektora jest najprawdopodobniej tylko rozmiar sektora logicznego, ponieważ większość istniejących interfejsów API, które odpytują rozmiar sektora nośnika, naprawdę tylko odpytują jednostkę adresowania — czyli rozmiar sektora logicznego. W tym przypadku wielkość sektora fizycznego jest wielkością sektora fizycznego, która jest rzeczywistą jednostką niepodzielności. Oto kilka przykładów interfejsów API, które pobierają rozmiar sektora logicznego:

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

Jak wykonywać zapytania dotyczące rozmiaru sektora fizycznego

Aby zapoznać się z przykładem kodu pokazującym, jak aplikacja może wykonywać zapytania dotyczące rozmiaru sektora fizycznego woluminu, zobacz https://msdn.microsoft.com/library/ff800831.aspx.

Chociaż powyższy przykład kodu umożliwia uzyskanie rozmiaru sektora fizycznego woluminu, przed użyciem niektórych czynników należy wykonać pewne podstawowe sprawdzanie poprawności zgłoszonego rozmiaru sektora fizycznego, ponieważ zaobserwowano, że niektóre sterowniki mogą nie zwracać poprawnie sformatowanych danych:

  • Upewnij się, że zgłoszony rozmiar sektora fizycznego jest >= zgłoszony rozmiar sektora logicznego. Jeśli tak nie jest, aplikacja powinna używać rozmiaru sektora fizycznego równego zgłoszonemu rozmiarowi sektora logicznego.
  • Upewnij się, że zgłoszony rozmiar sektora fizycznego jest potęgą dwóch. Jeśli tak nie jest, aplikacja powinna używać rozmiaru sektora fizycznego równego zgłoszonemu rozmiarowi sektora logicznego.
  • Jeśli rozmiar sektora fizycznego jest potęgą dwóch wartości z zakresu od 512 do 4 KB, rozważ użycie rozmiaru sektora fizycznego zaokrąglonego w dół do zgłoszonego rozmiaru sektora logicznego.
  • Jeśli rozmiar sektora fizycznego jest mocą dwóch wartości większą niż 4 KB, przed użyciem tej wartości należy ocenić zdolność aplikacji do obsługi tego scenariusza. W przeciwnym razie należy rozważyć użycie rozmiaru sektora fizycznego zaokrąglonego do 4 KB.

Użycie tej biblioteki IOCTL w celu uzyskania rozmiaru sektora fizycznego ma kilka ograniczeń:

  • Wymaga podwyższonego poziomu uprawnień. Jeśli aplikacja nie jest uruchomiona z uprawnieniami, może być konieczne napisanie aplikacji usługi systemu Windows, jak wspomniano powyżej.

  • Nie obsługuje woluminów SMB. Może być również konieczne napisanie aplikacji usługi systemu Windows w celu obsługi zapytań dotyczących rozmiaru sektora fizycznego na tych woluminach.

  • Nie można wydać do żadnego dojścia do pliku (IOCTL musi być wystawiony do dojścia woluminu).

  • Obsługiwane tylko w wersjach systemu Windows wymienionych na początku tego artykułu.

rekordy zatwierdzania są dopełniane do sektorów 512 bajtów

Aplikacje z magazynem danych zwykle mają jakąś formę rekordu zatwierdzenia, który przechowuje informacje o zmianach metadanych lub utrzymuje strukturę magazynu danych. Aby zapewnić, że utrata sektora nie ma wpływu na wiele rekordów, ten rekord zatwierdzenia jest zwykle wypełniany do rozmiaru sektora. W przypadku dysku o większym rozmiarze sektora fizycznego aplikacja będzie musiała wykonać zapytanie dotyczące rozmiaru sektora fizycznego, jak pokazano w poprzedniej sekcji, i upewnić się, że każdy rekord zatwierdzenia jest dopełniony do tego rozmiaru. Nie tylko pozwala to uniknąć cyklu odczyt-Modify-Write, co pomaga zagwarantować, że w przypadku utraty sektora fizycznego zostanie utracony tylko jeden rekord zatwierdzenia.

pliki dziennika są zapisywane w nieprzygotowanych fragmentach

Niebuforowane we/wy są zwykle używane podczas aktualizowania lub dołączania do pliku dziennika. Istnieje kilka sposobów, aby upewnić się, że te aktualizacje są poprawnie dopasowane:

  • Wewnętrzne buforowanie aktualizacji dziennika do zgłoszonego rozmiaru sektora fizycznego nośnika operacyjnego i wystawianie dziennika problemów jest zapisywane tylko wtedy, gdy jednostka sektora fizycznego jest pełna
  • Korzystanie z buforowanego we/wy

Problem 3: Formaty plików oparte na sektorach 512 bajtów

Niektóre aplikacje ze standardowymi formatami plików (na przykład VHD 1.0) mogą mieć te pliki zakodowane na twardo, aby zakładać rozmiar sektora 512 bajtów. W związku z tym aktualizacje i zapisy w tym pliku spowodują cykl odczytuModify-Write na urządzeniu, co potencjalnie spowoduje problemy z wydajnością i odpornością klientów. Istnieją jednak sposoby zapewnienia obsługi obsługi tego typu multimediów przez aplikację, na przykład:

  • Użyj buforowania, aby upewnić się, że zapisy są wykonywane w jednostkach rozmiaru sektora fizycznego
  • Zaimplementuj wewnętrznąModify-Write odczytu, która może pomóc w zapewnieniu, że aktualizacje są wykonywane w jednostkach zgłoszonego rozmiaru sektora fizycznego
  • Jeśli to możliwe, wyliczył rekordy do sektora fizycznego, w taki sposób, aby dopełnienie było interpretowane jako puste miejsce
  • Rozważ przeprojektowanie nowej wersji struktury danych aplikacji z obsługą większych sektorów

Problem 4. Zgłoszony rozmiar sektora fizycznego może ulec zmianie między sesjami

Istnieje wiele scenariuszy, w których zgłoszony rozmiar sektora fizycznego bazowego magazynu hostujący usługę Datastor może ulec zmianie. Najczęstszą z nich jest migracja narzędzia Datastor do innego woluminu, a nawet w sieci. Zmiana zgłoszonego rozmiaru sektora fizycznego może być nieoczekiwanym zdarzeniem dla wielu aplikacji i może spowodować, że niektóre aplikacje nawet nie mogą ponownie zainicjować.

Nie jest to najłatwiejszy scenariusz do obsługi i jest tu wymieniony jako porada. Należy wziąć pod uwagę wymagania dotyczące mobilności klientów i odpowiednio dostosować pomoc techniczną, aby zapewnić, że klienci nie mają negatywnego wpływu na korzystanie z nośników 512e.

4 KB nośnika natywnego

Nośnik emulacji 512 bajtów jest przeznaczony jako etap przejściowy między 512-bajtowym nośnikiem natywnym i 4 KB natywnych, a oczekujemy, że wkrótce po udostępnieniu 512e 4 KB natywnych multimediów. Istnieje kilka ważnych konsekwencji dla tych mediów, które należy zauważyć:

  • Rozmiary sektorów logicznych i fizycznych to 4 KB
  • Ponieważ nie ma warstwy emulacji, nieprzygotowane zapisy nie będą działać w magazynie
  • Brak ukrytej odporności — aplikacje działają lub nie działają

Mimo że firma Microsoft bada obecnie obsługę tych typów multimediów w przyszłej wersji systemu Windows i w razie potrzeby wyda artykuł BAZY wiedzy, deweloperzy aplikacji powinni rozważyć z góry zapewnienie obsługi tych typów multimediów.

Zamykanie

W tym artykule omówiliśmy wpływ, który ma wpływ na nośniki w dużych sektorach wraz z wieloma typowymi scenariuszami wdrażania. Widzieliśmy wpływ wydajności i odporności na odczyt-modyfikowanie-zapis, niektóre z interesujących scenariuszy, które ten nośnik może wprowadzić, oraz zestaw problemów, które mogą potencjalnie powodować z oprogramowaniem, co ostatecznie wpływa na użytkownika końcowego. Branża magazynowania szybko przechodzi na nośniki o większych rozmiarach sektorów, a wkrótce klienci nie będą mogli kupować dysków o tradycyjnych rozmiarach sektora 512 bajtów.

Jest to żywy dokument i jest przeznaczony jako pomoc dla deweloperów, aby pomóc zrozumieć to przejście. Należy rozpocząć rozmowę z odpowiednimi organizacjami, z klientami, informatykami i dostawcami sprzętu, aby porozmawiać o przejściu w dużym sektorze i sposobie, w jaki wpływa na scenariusze, które są dla Ciebie ważne.