Western Digital Advanced Format: осторожный дебют

Комментарии: 32

Традиционный путь развития жестких дисков основывается на постепенном увеличении плотности записи на магнитные пластины, однако он сопряжен с большими затратами времени, усилий и средств. Поэтому разработчикам приходится обращаться к новым технологиям, и одна из них – Long Physical Sector, представленная недавно Western Digital под названием Advanced Format.

Восьмая ревизия стандарта ATA/ATAPI предусматривает введение двух новых параметров, ранее не применявшихся для жестких дисков: Long Physical Sector (LPS, длинный физический сектор) и Long Logical Sector (LLS, длинный логический сектор). Первый подразумевает, что на этапе литографии, когда на магнитной пластине создаются секторы для последующей записи данных, она будет размечаться по-новому: вместо традиционных секторов по 512 байт будут применяться более емкие, по 1, 2 или 4 КБ. LLS же введен для того, чтобы разграничить понятия физического и логического сектора, к которому обращается ОС при файловых операциях (также известного как LBA). В традиционных HDD с секторами по 512 байт эти понятия фактически идентичны, потому ранее нужды в разделении LPS и LLS попросту не было. Теперь же возникает целый ряд нюансов, которые производителям жестких дисков придется решать.

Для начала поговорим о том, что дает переход на использование длинных физических секторов. Каждая ячейка на магнитной пластине снабжается служебной зоной Sync/DAM, служащей для позиционирования головок чтения/записи, и зоной ECC, хранящей коды коррекции ошибок на случай ошибки чтения. Кроме того, между всеми ячейками имеется небольшое пространство, минимизирующее взаимное влияние магнитных полей в них и деградацию заряда. Объем зоны ECC в современных HDD и эффективность алгоритмов восстановления данных при ошибке – один из ключевых факторов, влияющих на надежность хранения и скорость работы с содержимым. Чем большей плотности записи добиваются разработчики, тем хуже становится соотношение сигнал/шум, и следовательно, возникает больше ошибок чтения. Если контроллеру не удастся исправить их с помощью ECC, придется повторно считывать ячейку, что означает как минимум один дополнительный оборот пластин. На сегодняшний день типичным объемом зоны ECC считаются 40 байт на каждый 512-байтовый сектор. В будущем при дальнейшем увеличении емкости пластин разработчикам придется пойти на удвоение этого показателя, чтобы повысить шансы успешного восстановления.

Традиционные пластины с секторами по 512 байт

Переход на использование длинных секторов позволяет, во-первых, уменьшить число зон Sync/DAM и межсекторных промежутков во столько же раз, во сколько они длиннее обычных 512-байтовых, однако на самом деле это верхушка айсберга. Специфика алгоритмов восстановления данных по кодам ECC такова, что чем больший объем был считан, тем они эффективней, и следовательно, требуется меньше места для кодов. На практике это означает, что если для одного 512-байтового сектора необходимо 40 байт ECC, то для 4 КБ достаточно уже 100 байт. Несложно посчитать, что при этом экономится 220 байт. В сумме с другими служебными зонами, по данным WD, уже на современных HDD эффективность использования дискового пространства увеличивается на 7-11%, а в сравнении с будущими дисками с 80-байтовыми зонами ECC – и на все 22%. В первую очередь это играет на руку потребителю – на базе одних и тех же пластин и головок (что составляет львиную долю затрат на разработку HDD) вендоры смогут предложить на 10-20% более емкие накопители. В конце концов, использование физических секторов по 512 байт на сегодняшний день фактически бессмысленно: ни одна из современных файловых систем не использует кластеров такого размера, стандартным параметром NTFS при форматировании раздела является как раз 4 КБ, и запись и считывание данных осуществляется именно такими порциями.

Новые пластины с длинными секторами по 4 КБ

Есть у LPS/LLS и менее явные достоинства: устраняется лимит на емкость раздела более 2 TiB, существующий при 32-битной адресации и 512-байтовых секторах; большая эффективность алгоритмов коррекции ошибок означает, что быстродействие при чтении вырастет; меньшее количество физических секторов означает меньшую вероятность возникновения так называемых bad-блоков; уменьшенное в восемь раз число логических секторов означает радикальное уменьшение размера таблиц адресации и неизбежный рост эффективности работы контроллера при высокой нагрузке (большом числе запросов на случайное чтение и запись). Правда, на сегодняшний день об этом речь не идет, о чем – во второй части описания технологии.

WD Advanced Format: сложное решение под простым названием

Western Digital Advanced Format – вовсе не простое маркетинговое название LPS/LLS. Дело в том, что работу с физическими секторами по 4 КБ поддерживают не все ОС: в семействе Windows она появилась лишь с Vista, Server 2008 и 7, а остающиеся популярной XP и Server 2003 этой поддержки лишены. В стане MacOS и Linux все несколько оптимистичней: все мало-мальски актуальные версии этих ОС нормально работают с длинными секторами. Также стоит вопрос обратной совместимости и на аппаратном уровне: BIOS материнской платы, прошивка и драйвер контроллера дисков также должны поддерживать длинные ячейки. Поэтому WD пошла на сложный, однако необходимый на сегодняшний день шаг: в жестких дисках компании, использующих Advanced Format, на уровне контроллера реализована эмуляция обычных 512-байтовых секторов из физических 4-килобайтовых.

Advanced Format – эмуляция старого диска на новых пластинах

Накопитель при инициализации сообщает материнской плате, что по-прежнему используются короткие ячейки, а при получении от файловой системы логического адреса блока (LBA) транслирует его в адрес физического сектора. В результате появляется полная совместимость со старыми операционными системами, однако возникают и свои сложности. Во-первых, эта эмуляция требует дополнительной операции на пути между запросом на чтение/запись и осуществлением этой операции и, соответственно, увеличивает время исполнения. Во-вторых, она вызывает дополнительную нагрузку на вычислительное ядро контроллера диска и, таким образом, снижает эффективность работы прошивки. В-третьих, в любом случае теперь при чтении даже 512 байт данных физически диску придется считать 4 КБ и 3,5 КБ из них отбросить (очень похоже на write amplification в SSD), а если нужно считать подряд два логических сектора, принадлежащих разным физическим – придется обрабатывать сразу 8 КБ. В-четвертых, и это самое важное, появляется главная проблема этой технологии – огромное падение производительности при использовании неправильно созданных разделов.

Дело в том, что старые операционные системы (до Vista) при создании раздела начинают разметку с блока №63 (LBA63), это «наследие» еще DOS, ныне ничем не обоснованное. Подчеркнем, что проблема эта возникает только при разметке диска из-под Windows XP и более ранних ОС либо клонировании разделов с помощью утилит, не поддерживающих 4-килобайтовые секторы, в любой ОС. Windows Vista и 7 размечают первый раздел с 2048-го сектора, а следующие – с ближайшего после окончания первого раздела кратного восьми, поэтому они сразу получается выровненными. Для HDD с секторами по 512 байт никакой проблемы также нет – каждая из ячеек существует физически и может быть адресована напрямую. Для 4-килобайтовых ячеек начало с нечетного логического сектора означает, что кластер операционной системы будет размещен сразу на двух физических ячейках, и производительность HDD очень сильно снизится.

Невыровненный кластер файловой системы на двух физических секторах

К примеру, если диску нужно подряд считать или записать n кластеров, на самом деле придется обращаться к n+1 ячеек, а если речь идет об операциях со случайным доступом и малым размером блоков, можно смело говорить об удвоении фактически считываемых и записываемых данных. В случае же если две ячейки находятся на разных дорожках, то к обычному процессу «адресация-позиционирование-чтение» добавляется еще поворот пластин, поиск второго сектора и позиционирование, что для HDD с частотой вращения 7200 об/мин добавляет минимум 8,3 мс. Поэтому крайне важно, чтобы созданный на диске раздел был «выровнен» с физическими ячейками, т.е. его начало совпадало с началом сектора на HDD.

Выравнивание разделов – залог быстродействия

Добиться этого WD предлагает несколькими способами. Первый – можно просто замкнуть 7 и 8 контакты диска перемычкой. Тогда контроллер при адресации станет прибавлять 1 к получаемому от ОС LBA (соответственно, при обращении в LBA63 HDD на самом деле обратится в 64-й логический сектор), весь массив адресов сдвинется и совпадет с физическими ячейками. Этот вариант работает только в случае создания единственного раздела и только до разметки диска, если установить перемычку после нее – раздел перестанет распознаваться, если создать второй раздел – он не будет выровнен, поскольку между ним и первым снова будет промежуток в 63 логических сектора.

Второй, более универсальный вариант, предполагает использование утилиты WD Align, доступной бесплатно с сайта производителя. Она разработана компанией Paragon Software, известной своим ПО для работы с дисками, и позволяет «на лету» выровнять разделы в соответствии с физическими секторами без потери данных и необходимости их куда-либо копировать. Поддерживается работа как с загрузочного диска (при этом операция пройдет быстрее), так и прямо из-под работающей ОС (выравнивание происходит после перезагрузки, аналогично клонированию раздела). При этом уже записанные файлы копируются на новое место (скорость при этом примерно соответствует обычному копированию), а пустое пространство просто быстро переразмечается с внесением соответствующих изменений в MFT. К примеру, пустой раздел емкостью 2 ТБ был выровнен примерно за 3 минуты. При запуске утилита проверяет, действительно ли используется диск с Advanced Format и раздел не выровнен, поэтому риска случайного выравнивания нормального раздела нет.

 

Операционная
система
Новый диск,
1 раздел
Новый диск,
>1 раздела
Клонирование раздела менеджером
(любое кол-во разделов)
USB-диск
Windows XP перемычка
или WD Align
WD Align WD Align WD Align
Windows Vista не требуется не требуется
Windows 7
Mac OS не требуется
Linux

Тестирование

Перейдем от теории к практике. На сегодняшний день единственными HDD, в которых применены секторы емкостью 4 КБ, являются Western Digital Caviar Green с суффиксом EARS в названии модели. Что характерно, это первые накопители экономичной серии, предназначенной в качестве дисков для высокоемких, тихих и холодных систем хранения, в которых применен буфер емкостью 64 МБ – необходимость оперировать 4-килобайтовыми блоками вместо 512-байтовых предъявляет повышенные требования к кэшу.

Мы протестировали топовую модель этой серии – WD Caviar Green WD20EARS емкостью 2 ТБ. Диск форматировался в Windows XP и Windows 7 (таким образом снимались показания для выровненного и не выровненного разделов). Для сравнения использовался HDD WD AV-GP WD20EVDS – аналог Caviar Green, позиционируемый как накопитель для медиасерверов, записывающих устройств и т.п. Этот диск использует пластины с обычными секторами и оснащен буфером емкостью 32 МБ. Оба тестируемых устройства основаны на четырех пластинах емкостью 500 ГБ, однако напрямую их сравнивать нельзя: AV-GP оптимизированы под однопотоковые линейные операции, а у WD20EARS еще и вдвое больший кэш. Однако представление о том, какое влияние на быстродействие оказывает эмуляция в контроллере и как сказывается на ней невыровненность раздела, можно составить. Для снятия показателей линейных скоростей и времени отклика, а также для эмуляции рабочей станции, файлового и веб-серверов использовалась утилита IOMeter в режиме дискового доступа (без разбиения на разделы), также из-за особенностей работы IOMeter с разделами для иллюстрации необходимости выравнивания вместо него использовался Intel NAS Performance Toolkit.

Как видно из диаграмм, на линейных операциях необходимость трансляции логических адресов в физические на уровне контроллера практически не сказывается. WD20EARS демонстрирует неплохую производительность, заметно опережая своего собрата. Сложно сказать, чем обусловлено это превосходство: более емким буфером, большей итоговой плотностью записи из-за отсутствия большинства сервисных зон, или просто особенностями прошивки. Неудивительно, что WD решила «обкатать» Long Physical Sector именно на серии Caviar Green – эти HDD предназначены в первую очередь для домашних высокоемких хранилищ, где в основном на них записываются крупные мультимедийные файлы. В таком случае характер обращений к ним будет именно линейным (если не считать файлообменных систем), и проблем из-за эмуляции возникать не будет, поскольку в значительной мере они будут нивелироваться эффективностью кэширования.

В то же время, судя по показателям времени доступа на чтение и запись, эмуляция 512-байтовых секторов при адресации сказывается очень сильно: если для чтения показатели еще терпимы (20,5 мс у WD20EARS против 17,4 мс у WD20EVDS), то при записи этому диску не помогает даже кэширование – почти 33 мс ставят крест на возможности использования этого HDD в качестве системного.

Наиболее ужасны показатели производительности при работе с мелкими файлами: вплоть до размера блока 16 КБ WD20EARS записывает их со скоростью до 5,5 МБ/с (4 КБ, которым равен один кластер файловой системы, пишутся в среднем при 1,4 МБ/с, а пресловутые 512 байт – вообще на смехотворных 50 байтах в секунду). Причина этому проста: чем меньше файлы и чем их больше, тем тяжелее нагрузка на контроллер, которому приходится выполнять намного больше операций для нахождения реального места назначения отправленных ему на сохранение данных. Лишь начиная с 32 КБ эффективность эмуляции резко возрастает – аж до 92,6 МБ/с.

Диаграммы Intel NAS Performance Toolkit намекают, что WD стоит не просто наклеивать на упаковку своих новых HDD скромную инструкцию о том, как нужно их размечать под разными ОС, а не мешало бы это делать крупными красными буквами. Скорость записи на невыровненный раздел по сравнению с правильно размеченным HDD отличается почти в 4 раза! Под тяжелой нагрузкой эффективность падает в 5 раз, при одновременной работе двух потоков с линейным доступом – в полтора-два раза. Лишь при линейном чтении в один поток разницы почти нет – диску все равно, как соотносятся кластеры с секторами, поскольку он все равно проходит по ним последовательно.

Итоги

Однозначные выводы по итогам этого тестирования делать сложно. С одной стороны, переход на использование секторов емкостью 4 КБ – оправданная и давно назревшая мера, к которой в ближайшее время начнут обращаться и другие производители жестких дисков. Преимуществ у этого подхода много, а недостаток всего один – несовместимость с ОС прошлых поколений. Бороться с ним можно активно, как это делает WD посредством эмуляции в поддерживающих Advanced Format дисках, а можно пассивно – выжидая, когда инсталляционная база ПК с аппаратными ограничениями на использование 4-килобайтовых ячеек в HDD и под управлением Windows XP станет достаточно малой, чтоб ею можно было пренебречь. Вероятнее всего, этот момент настанет ближе к 2014 г., когда Microsoft окончательно прекратит поддержку Windows XP. Однако это не означает, что до тех пор мы сможем наблюдать новую технологию только в виде Advanced Format, вполне вероятно, что накопители более высокого класса для производительных ПК будут выпущены с отключенной эмуляцией и позиционированием на современные ПК, работающие под управлением современных ОС.

Что касается конкретных HDD Western Digital Caviar Green серии EARS, то, рассматривая их в качестве варианта покупки, нужно быть осторожным: они подойдут только в качестве хранилища, если же планируется мало-мальски серьезная нелинейная нагрузка – стоит обратить внимание на традиционные модели с суффиксом EADS. В данном же случае перед нами скорее «полевое испытание», и WD в чем-то даже заслуживает похвалы за то, что в компании рискнули самостоятельно начать подготовку рынка к будущему переходу на использование длинных секторов.

Продукт предоставлен Trinity Electronics
  • ITC.UA

    Комментарии к статье:

    [drupal=45448]Western Digital Advanced Format: осторожный дебют[/drupal]

    [quote]Традиционный путь развития жестких дисков основывается на постепенном увеличении плотности записи на магнитные пластины, однако он сопряжен с большими затратами времени, усилий и средств. Поэтому разработчикам[/quote]

    • NOD32

      Дааа… Новость просто «свежачёк», как всегда в стиле ИТС ((((((((

      • Тарас Олейник

        Подскажу на всякий случай: это не новость, это тестирование жесткого диска WD с новой разметкой и режимом совместимости со старой.

    • zmeuka

      а в имеющихся дисках эта эмуляция каким-нибудь джампером не отключается?
      всё-таки намного интереснее добавить в сравнение «родной» режим

      • Alexsandr

        [quote=zmeuka;454352]а в имеющихся дисках эта эмуляция каким-нибудь джампером не отключается?[/quote] Нет.

    • Alexsandr

      [i] меньшее количество физических секторов означает меньшую вероятность возникновения так называемых bad-блоков[/i]
      Меньшее кол-во на бумаге, физически площадь поверхности используется более полно насколько это видно, а значить что вероятность бедов выше, но теперь без будет не 512байт, а 4 килобайта.

      а в целом материал непонятно для чего подан. Само упоминание технологии было в тестах винчестеров. А здесь упоминание без подробного тестирования что и как никчему получается. Да и минусы подобной технологии не мешало бы озвучить, ведь они есть. А так просто рекламная информация.

      • nemesis

        А какие еще минусы остались? Выравнивание  и, собственно, сама эмуляция озвучены. Что еще осталось? Причем и выравнивание, и эмуляцию трудно назвать «чистым» минусом технологии (не путать с конкретным диском!), так как это, по сути, адаптация под ХР и другие несовместимые..

        • Alexsandr

          [quote=nemesis;454445]А какие еще минусы остались? Выравнивание и, собственно, сама эмуляция озвучены.[/quote] жутко медленная работа при записи файлов. Особенно если не было выравнивания. [quote=nemesis;454445]так как это, по сути, адаптация под ХР и другие несовместимые..[/quote] вопрос на засыпку умеет ли последняя программы для дефрагментации работать с блоками не по 512 байт а по 4килобайта? Вопрос для всех кто знает. Просто интересно хоть какое-то служебное ПО способно работать не с 512байтами?

          • Евгений Пугач

            дефрагментатор работает в файловом режиме, ему глубоко плевать, какие там блоки. Тем более пишет он в большинстве случаев из кэша линейно.

          • Inline-CODER

            [quote] @[b]Евгений Пугач[/b]: [/quote] 
            дефраментатор працює у файловому режимі? ?? шось я явно пропустив… можна пруфлінк?

      • Тарас Олейник

        [quote] А здесь упоминание без подробного тестирования что и как никчему
        получается. Да и минусы подобной технологии не мешало бы озвучить, ведь
        они есть. А так просто рекламная информация.[/quote] 
        А если все же напрячься, пересилить себя и таки дочитать до диаграмм и описания результатов? :)

        • Alexsandr

          [quote=Тарас Олейник;454524]А если все же напрячься, пересилить себя и таки дочитать до диаграмм и описания результатов? :)[/quote] После этой фразы я осмотрел материал ещё раз и заметил что он состоит из нескольких частей :) Не заметил вчера к вечеру уже, прошу прощения за необоснованные претензии.

          Тогда просто одна просьба добавить тесты в реальных приложениях. как-то архивирование разархивирование, копирование с раздела на раздел…

      • Евгений Пугач

        Ну как это. Площадь поверхности используется ровно так же, просто под пользовательские данные ее теперь выделено больше. А чем меньше каждый сектор соседствует с другими и получает от них наводки, тем меньше вероятности потери заряда.
        Интересно, насколько вам подробное тестирование-то надо? Вот это не подробное? Или вы просто не нажали на кнопку «следующий раздел»? :)
        Минусов этой технологии, если она будет нативной (без эмуляции) в современных ПК я не наблюдаю.

    • kOzel

      «Какие-либо выводы по итогам этого тестирования делать сложно» Так для чого писати бояни коли узагальнити нормально не можете.  Тим більше тема обсмоктана тисячу разів

      • Тарас Олейник

        Ну, подразумевалось, полагаю, что ОДНОЗНАЧНЫХ выводов — в стиле «рулез» или «сакс» (которые так любят некоторые читатели) — в данном случае сделать не получится.

    • sonylover

      Развитие винчестеров всегда приветствуется! ))
      А то SSD — ОЧЕНЬ дОроги пока…

    • sivsoft

      спасибо за тестирование.
      очень интересная тема.
      Но вот итоги каие-то слишком краткие. Зачем ждать окончания поддержки XP если Vista и семёрка по вашим словам полностью поддерживают сектора любых размеров?
      В чём причина замедления массированной записи даже на выровненных разделах?
      Есть ли разница в производительности винта с Advanced Format при использовании его в XP и в семёрке?
      И кстати интересный факт: ещё под досом в бут секторе было поле, отвечающее за физический размер сектора. Если не ошибаюсь, можно было использовать сектора размером 128, 256, 512 байт. И насколько я помню, в досовской команде format был параметр для выбора размера сектора при форматировании дискет.

      • Евгений Пугач

        1) потому что только полное прекращение поддержки подстегнет массовый переход на более новые ОС, тут уж ничего не поделаешь. А добровольно ограничивать круг потенциальных потребителей или нарываться на волну возвратов устройств, выпуская диски «только для висты и 7″, никто пока не хочет.
        2) В эмуляции, она много ресурсов требует.
        3) нет, если раздел выровнен.
        4) за сообщение биосу и драйверу ОС о физическом размере кластера отвечает прошивка контроллера и данные в сервисной зоне на пластинах, загрузочный сектор идет уже после них. В ATA/ATAPI-8 как раз предусмотрели возможность сообщить одновременно количество реальных секторов/голов/цилиндров и логических.

        • sivsoft

          1) в таком случае разумно было бы выпустить устройство с джампером, отключающим эмуляцию, чтобы это устройство могло работать в «родном» режиме под теми ОС, которые это поддерживают. Возможно проблема ещё и в старых биосах.
          2) странная какая-то эмуляция. Я бы даже сказал, кривая. Причём при чтении эта же эмуляция почему-то не мешает обгонять обычный винт. А вот при массированной записи почему-то тормозит. Причём речь идёт о линейной записи на выровненный раздел (то есть запись в последовательные логические сектора элементарно преобразуется в запись в последовательные физические сектора).
          4) я не хотел сказать, что DOS был лучше современных Осов. Понятно, что со времён доса всё изменилось.
          Спасибо вам за ответы. Желательно было об этом написать в итогах.

        • Alexsandr

          [quote=Евгений Пугач;455413]только полное прекращение поддержки подстегнет массовый переход на более новые ОС, тут уж ничего не поделаешь. [/quote] кроме Ос ещё нужно что бы и ПО понимало новые размеры. А это дольше чем переход на новые ОС.

    • yurius

      Хороший пример взгляда на привычные вещи с другой стороны. В IT ведь многие стандарты достались с очень дремучих времен. Некоторые стандарты пересматриваются в связи с тем, что мешают дальнейшему движению вперед (к примеру ограничение объема  SD->SDHC->SDXC), а некоторые, не мешающие так явно, остаются с нами. Это один из таких примеров. А ведь таких примеров еще огого сколько и пока до них доберутся.

      • Alexsandr

        [quote=yurius;455232]Некоторые стандарты пересматриваются в связи с тем, что мешают дальнейшему движению вперед (к примеру ограничение объема SD->SDHC->SDXC)[/quote]только SDHC ограничен помнится несколькими терабайтами по файловой системе. к примеру малый размер кластера как мы видим убыстряет работу с маленькими файлами пр записи.

      • sivsoft

        По поводу SD->SDHC складывается такое впечатление, что ограничения были заложены сознательно для того, чтобы потом можно было срубить бабла на продаже новых устройств с поддержкой SDHC. Ведь по себестоимости устройства SD и SDHC эквивалентны.

    • Влад Шокота

      Очередной гвоздь в крышку Windows XP. [img]http://itc.ua/sites/all/libraries/tinymce/jscripts/tiny_mce/plugins/emotions/img/smiley-cry.gif[/img]

    • nemesis

      Скажите Евгений, а не приходила ли Вам в голову идея вручную «выровнять»
      диск? Я специально выделил слово «выровнять» потому что никакого выравнивания при этом не происходит.
      Вот что я имею ввиду:
      В настоящий момент проблема «Сектор 63″ носит чисто формальный характер.
      Ведь нигде не сказано что раздел должен начинатся именно с 63 сектора (кстати, физически это 64-й сектор). Это история. Традиция. Привычка,
      если хотите, но НЕ стандарт и НЕ обязательство.
      В современных дисках давным-давно используется адресация LBA, а сам раздел в таблице разделов, которая расположена в самом первом секторе, описывается двумя значениями: адрес раздела (или смещение) и его длина. Так вот, этот самый адрес первого раздела по традиции имеет значение 63 (3F). А что если его сразу после создания раздела вручную изменить на 64, а только потом отформатировать (создать файловую систему)? Должно получится то же что и выравнивание, но только вручную.

      • Alexsandr

        [quote=nemesis;456436]А что если его сразу после создания раздела вручную изменить на 64, а только потом отформатировать (создать файловую систему)? [/quote] На винте перемычка ещё должна быть, которая делает автоматом переадресацию на +1сектор. Правда не упоминается что будет с последним сектором.

        • Евгений Пугач

          теоретически последний станет нулевым (число секторов, по крайней мере, при этом остается тем же, а не на 1 меньшим).
          если поставить перемычку после того, как раздел уже был создан, он не выровняется, он перестанет видеться.

      • Евгений Пугач

        Вы как-то странно статью читали :) Там тесты с выровненным и невыровненным разделами. 63й сектор — это действительно физический 64й, потому что нумеруются они с 0.
        Какой смысл в подобных манипуляциях? Да, можно с помощью diskpar, например, создать раздел с каким угодно сдвигом, хоть на 1 сектор, только зачем? Любые современные менеджеры разделов и так начинают их с 2047-го, и все выравнивается.

        • nemesis

          Я все видел. Но я не могу понять почему вы aligned диск тестировали в
          Win7, а unaligned в WinXP. Добавьте тогда еще и результаты
          WinXP+aligned..

          • Евгений Пугач

            Я обе тестировал в Win7, в WinXP только раздел создавался. Точно так
            же я мог напрямую создать невыровненный раздел в семерке с помощью
            diskpar.

    • Влад Шокота

      От этой технологии только одни проблемы.

    • vovanblin

      Одно не понятно! Почему не сделали выключатель эмуляции?
      А еще, где обещанные 10% дискового пространства?

Новости партнеров