Ncq hdd что это

Обновлено: 05.07.2024

В первой части нашего обзора дисков WD2500KS и WD2500JS мы в деталях познакомились с достаточно удачными настольными накопителями среднего ценового диапазона серий WD Caviar SE16 и Caviar SE. Тогда мы обратили внимание на некоторую неясность с поддержкой Native Command Queuing (NCQ) в данных моделях дисков WD. Дело в том, что в этих дисках WD перешла на применение нового контроллера Marvell 88i6545 с поддержкой интерфейса Serial ATA со скоростью 3,0 Гбит/с и NCQ. Однако по некоторой информации от сотрудников WD компания решила поставлять потребителям свои настольные диски серий KS, KD и JS с отключенной NCQ, поскольку с включенной NCQ эти изделия демонстрируют худшую (по мнению WD) производительность при выполнении типичных для настольных ПК задач (о чем даже есть соответствующие официальные презентации WD, см., например, здесь (PDF, 1 Мбайт)).

The JS models !!do!! support NCQ, I am not going further with this discussion about the JS model not supporting NCQ according to you, you are wrong.

Вот так вот! И среди заокеанских официальных ресурсов невежливость не редкость… Но самое интересное началось позднее: в том самом разделе FAQ WD, посвященном NCQ, спустя день после моего ответа на приведенную выше цитату УПОМИНАНИЕ О ПОДДЕРЖКЕ NCQ моделями WDxxxxJS просто-напросто ИСЧЕЗЛО. :) Значит, все-таки WD НЕ поддерживает NCQ в JS? И я изначально в этом споре был прав? Вроде бы так, поскольку через день тот же самый «специалист по техподдержке» из WD написал мне, что, дескать,

и что я снова почему-то неправ (логики этого «пассажа» я вообще не понял :); учитесь умению вести спор у таких вот спецов по техподдержке, оголтелые бойцы нашего форума ;)). Однако из доверенных источников (благо, в WD много и хороших людей) недавно мне поступила информация, что WD в последнее время склоняется к тому, чтобы некоторые партии JS все же поставлялись со включенной NCQ…

В общем, пока что неразбериха с этим вопросом не утряслась, и несколько огорчает лишь то, что WD не позволяет самому пользователю решать, включать ему NCQ в дисках WDxxxxKS/JS или нет. Последнее было бы вполне логично и, если угодно, гуманно. :)

Беглая проверка «пустующего» джампера 7-8 на задней панели жестких дисков WDxxxxJS показала, что он не позволяет оперировать поддержкой NCQ в этих дисках. Поэтому нам пока остается довольствоваться тем, что есть. И в этой части нашего обзора мы на основе реальных испытаний данных жестких дисков попробуем выяснить текущий статус поддержки NCQ в дисках WD и сравнить их с некоторыми дисками конкурентов, таки поддерживающими NCQ.

Испытания проводились на стенде и по методике, описанным в первой части. Для проверки работы NCQ (и SATA II) с дисками использовался PCI-контроллер на чипе Silicon Image 3124-2, а для случая «без NCQ» использовался SATA-контроллер южного моста ICH5 чипсета Intel 875P.

  • WD2500JD (выпуск 2004 г., NCQ однозначно отсутствует)
  • WD2500JS (Serial ATA II, наличие NCQ под вопросом)
  • WD2500KS (s/n: …68912, условно 100-ГБ пластины, обозначаем как hs)
  • WD2500KS (s/n: …79558, условно 80-гигабайтные пластины)
  • Samsung SP2504C (Serial ATA II, NCQ есть)
  • Hitachi Deskstar T7K250 (Serial ATA II, NCQ есть)

Проверка статуса NCQ в тестируемых дисках утилитой HD Tune 2.52 показала, что флаг NCQ отключен во всех изученных моделях WD2500JS и WD2500KS.


Однако та же утилита показывала, что для исследованных мной одновременно с ними дисков WD4000KD флаг NCQ присутствовал (!), хотя по неоднократно полученной из разных «мест» WD (в том числе, из официальной страницы FAQ, см. линк выше) информации накопитель WD4000KD не должен был бы обладать поддержкой NCQ.


Масла в огонь подлила строчка на этом же скриншоте, что данный жесткий диск поддерживает интерфейс SATA II, хотя и по спецификациям WD, и по информации от контроллера SiI3124-2

он не должен был бы этого делать, поскольку SATA II подразумевает, кроме прочего, поддержку скорости 3 Гбит/с. Таким образом, даже в правдивости такого, казалось бы, надежного инструмента, как чтение внутренних параметров диска, в отношении текущих продуктов WD возникли некоторые сомнения. (К слову, с дисками, например, Hitachi и Samsung таких подозрений не возникало.) То есть несмотря на отсутствие флага поддержки NCQ в данных накопителях по утилитам, неразбериха с ответами и утверждениями WD по этому поводу все же вынудила меня попытаться проверить наличие/отсутствие NCQ в них на практике по тестам. А заодно в наглядном виде разобраться, как ведут себя диски с контроллером SiI3124 с и без поддержки NCQ, что само по себе тоже небезынтересно. И что дает применение NCQ в разных вариантах реализации (от разных производителей).

Результаты тестов физических параметров

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

Со всеми дисками в этой части обзора, кроме WD2500JD, контроллер SiI3124 работает по интерфейсу Serial ATA со скоростью передачи 3 Гбит/с, однако из-за ограничений пропускной способности шины PCI32/33 МГц эта скорость на диаграмме не прослеживается. Огорчаться по этому поводу не стоит, поскольку контрольные испытания с этим же контроллером на высокоскоростной шине PCI-X показали, что сколько-нибудь заметных преимуществ в быстродействии этих дисков скорость интерфейса SATA 3 Гбит/с не дает. В данном случае мы просто убедились, что со скоростью SATA у всех участников все в порядке. Разве что Samsung демонстрирует чуть худшие показатели, чем Hitachi и WD.

Все в порядке и со средним временем доступа к дискам при переходе от одного контроллера к другому. Значения совпадают практически с точностью измерений.

Об эффективности работы алгоритмов отложенной записи firmware диска и кэширования записываемых данных в буфере диска можно попытаться судить по тому, как падает среднее измеренное операционной системой время доступа при записи относительно чтения при включенном write-back кэшировании накопителя. Для этого мы используем результаты теста C'T H2benchW.

Особых различий по среднему времени доступа при записи (с учетом кэширования) между хост-контроллерами здесь тоже не видно, хотя с SiI3124 все же значения оказываются, как правило, немного меньше, чем с ICH5. Влияния NCQ здесь не прослеживается ввиду единичной глубины очереди запросов теста. Теперь перейдем к тестам производительности в приложениях.

Быстродействие в приложениях

Сначала посмотрим, насколько диски оптимизированы для многопотоковой работы в программе NBench 2.4, где файлы размером 100 Мбайт записываются на диск и читаются с него несколькими одновременными потоками — как близко, так и далеко отстоящими друг от друга на диске (в данном случае используется FAT32). На диаграмме ниже показаны только усредненные по нескольким паттернам результаты для чтения и записи, а подробности (без комментариев) можно найти на отдельной странице.

При многопотоковой записи можно выделить несколько важных моментов. Во-первых, для дисков с поддержкой NCQ есть однозначно положительное влияние реорганизации очереди команд при записи (напомним на всякий случай, что NCQ работает не только на операциях чтения, но и на операциях записи, а также на чередующихся командах). Так, для диска Hitachi средний показатель этого теста при записи улучшился на 7%, а для диска Samsung — на все 12%. Вместе с тем, для диска WD2500JD (у которого нет и не может быть поддержки NCQ) результаты с обоими контроллерами практически идентичны (на полпроцента выше для SiI3124 за счет особенностей драйверов). Поэтому то, что для дисков WD2500KS и WD2500JS мы также наблюдаем почти равные результаты при записи с разными контроллерами (на те же 0,5-1% выше с SiI3124), является подтверждением факта, что NCQ в данных дисках не задействовано (по крайней мере, при записи).

При многопотоковом чтении, однако, ситуация не столь однозначная. Работа NCQ с контроллером SiI3124 дает положительный (+20%!) эффект для диска Hitachi и явно отрицательный эффект (-50%. ) для диска Samsung. Тогда как для диска WD2500JD (без какого-либо влияния NCQ) только драйверы контроллера SiI3124 обеспечивают падение производительности в данном тесте на 13%! Однако для других винчестеров WD, WD2500JS и WD2500KS, мы, напротив, наблюдаем соответственно 7,4% и 10-12% прироста средней производительности при многопотоковом чтении благодаря использованию контроллера SiI3124. То есть этот прирост вполне можно было бы приписать и работе NCQ в дисках WD2500xS, и/или особенностям взаимодействия драйверов контроллера SiI3124 с firmware новых винчестеров WD (хотя со старыми дисками WD эти же драйверы дают эффект противоположный).

В популярных тестах Disk WinMark 99 из пакета WinBench 99 (напомню, что мы проводим эти тесты для «начала» и для «середины» (по объему) физического носителя и результаты усредняем) ситуация тоже далека от однозначной.

В Business-тесте прирост показателей от использования контроллера SiI3124 заметно выше для дисков Hitachi и Samsung, где поддержка NCQ присутствует. Вместе с тем, прирост от SiI3124 выше и для диска WD2500JS по сравнению с WD2500JD, поэтому говорить об отсутствии NCQ в WD2500xS на основании этих данных было бы неправильно, как и утверждать о наличии поддержки NCQ.

В тесте High-End картина еще более запутана: прирост средних показателей при переходе от ICH5 к SiI3124 составляет 15-20% для Samsung SP2504C, 16-18% для Hitachi T7K250, лишь 12% для без-NCQ-шного WD2500JD, и почти треть (26-32%) для WD2500JS и примерно столько же (23-28%) для WD2500KS! Впрочем, учитывая то, что драйверы контроллера SiI3124 уже не раз были заподозрены в «пристрастии» к тестам WinBench 99 Disk WinMark, утверждать что-либо определенное по отношению к NCQ в данном случае было бы опрометчивым.

Теперь — комплексные «трековые» тесты оценки производительности дисков в пакетах PCMakr04 и C'T H2BenchW.

В дисковом тесте популярного Futuremark PCMark04 ситуация достаточно однозначна: при использовании NCQ (в дисках Samsung и Hitachi) есть прирост производительности от 2,3 до 5,4% соответственно, тогда как для всех дисков WD2500xx, напротив, с контроллером SiI3124 результаты ниже, чем с ICH5 — на 2,5% у JD, на 1,1% у JS и на 0,7-1,2% у KS. Здесь с большой долей уверенности можно утверждать, что NCQ у данных дисков WD не работает.

Между тем, в похожем тесте C'T H2benchW, как правило, более чувствительном к различиям между моделями накопителей, картина иная. Здесь уже все диски WD ведут себя совершенно одинаково с обоими хост-контроллерами (в пределах погрешности измерений), вроде бы доказывая тем самым отсутствие поддержки NCQ. Однако же с задействованной NCQ в дисках Samsung и Hitachi наблюдается картина противоположная: производительность падает на 2-3%. Впрочем, последнее как раз можно списать на негативные результаты работы NCQ, неоднократно отмечаемые в прессе и даже самими производителями винчестеров (см. выше).

По скорости работы дисков с временным файлом программы Adobe Photoshop четких выводов о поддержке NCQ сделать нельзя поскольку результаты на разных контроллерах почти совпадают для всех дисков.

Тесты в Intel Iometer

Для имитации работы дисков в различных приложениях мы также используем специальные паттерны в программе Intel IOmeter: DataBase, File Server, Web Server и Workstation, а также паттерны чтения, записи и копирования мелких и крупных файлов по случайным адресам в пределах всего диска с четырьмя очередями запросов (1, 4, 16 и 64). Подробные результаты по каждому из паттернов представлены без комментариев на отдельной странице и в наших предыдущих обзорах дисков Hitachi, Samsung и WD, а здесь мы покажем лишь усредненные результаты. Усреднение проводилось геометрически по всем очередям запросов и паттернам без весовых коэффициентов.

Прежде всего, нужно отметить, что анализ результатов тестов в данных паттернах в зависимости от глубины очереди явных свидетельств о наличии или отсутствии NCQ в данных случаях не дает, поскольку и драйверы контроллеров, и кэш-память самих дисков достаточно активно использует кэширование чтения и записи. Поэтому прирост показателей тестов при возрастании глубины очереди есть даже там, где NCQ нет по определению. По этой же причине, кстати, малопоказательны те простые тесты, которые делают попытку определить наличие/отсутствие и «эффективность» NCQ, посылая простые запросы с возрастающей глубиной очереди.

Могу лишь отметить, что если для WD2500KS с контроллером SiI3124 в паттернах DataBase, File Server, Web Server и Workstation зависимости быстродействия от глубины очереди (от 1 до 16) почти нет (хотя она и появляется при глубине очереди 64), и в среднем для всех дисков WD результаты с контроллером SiI3124 существенно ниже, чем с ICH5, то для дисков Hitachi T7K250 и Samsung SP2504C с контроллером SiI3124 такая зависимость от глубины очереди все же есть, и результаты с SiI3124 для них явно выше, чем с ICH5. Исходя из этого можно заключить, что в данных дисках WD Caviar SE16 и SE поддержка NCQ отсутствует (или реализована крайне неэффективно).

Теперь — наши паттерны имитации работы с файлами (чтение/запись/копирование), более близкие по назначению пользователям обычных настольных ПК (подробные результаты — на отдельной странице). Снова, из-за кэширования контроллеров и дисков однозначных выводов о наличии NCQ по графикам зависимости от глубины очереди запросов здесь сделать не удается, хотя с контроллером SiI3124 ряд дисков (в том числе, Samsung) ведет себя иногда даже хуже, чем с мостом ICH5. Например, видно, что в паттернах копирования файлов результаты для дисков WD с SiI3124 оказываются ниже, чем с ICH5.

По результатам геометрического усреднения этих шести паттернов (чтение, запись и копирование файлов по случайным адресам) диски WD в среднем теряют от 3 до 5% производительности при переходе от ICH5 к SiI3124. Тогда как накопители Hitachi и Samsung, напротив, немного прибавляют (2-3%).

Поразительно ровная для дисков WD картина наблюдается в паттернах дефрагментации.

Разница для них между контроллерами SiI3124 и ICH5 практически отсутствует, а минимальные различия обусловлены скорее различиями драйверов самих контроллеров. Впрочем, это различие драйверов достаточно ярко проявляется с дисками Hitachi и Samsung, где в зависимости от паттерна (имитирующего ту или иную файловую систему) явно быстрее то один, то другой хост-контроллер. Хотя заподозрить в данном случае влияние NCQ сложно ввиду единичной глубины очереди запросов, посылаемых тестом.

В паттернах потокового одновременного чтения-записи крупными или мелкими блоками (что характеризует, например, работу ПК при редактировании цифрового видео или в режиме цифрового магнитофона с таймшифтингом) ситуация для дисков WD повторяется. Практически независимо от глубины очереди запросов результаты у WD2500xx одинаковы на обоих контроллерах (за редкими исключениями), подтверждая отсутствие поддержки NCQ в этих дисках. Тогда как для NCQ-дисков Hitachi и Samsung мы можем видеть однозначный и порой весьма значительный прирост скорости при глубине очереди =4, если вместо ICH5 используется SiI3124.

Заключение

Итак, проведенные нами испытания свидетельствуют, что поддержки Native Command Queuing в протестированных накопителях WD2500KS и WD2500JS, по всей видимости, нет, как о том и говорили информационные утилиты. К этому же, в конечном итоге, склоняются и разрозненные, а порой и противоречивые данные самого производителя дисков. Хотя в контроллерах этих дисков поддержка NCQ изначально и была предусмотрена. Жаль, что WD пока не хочет разрешить конечному пользователю самому решать, включать или отключать ему работу NCQ в дисках WD. Поэтому если вам такая поддержка все же необходима (в чем, кстати, у меня нет однозначной уверенности ;)), придется приобретать диски «профессиональных» серий WD Caviar RE2 или WD Raptor X.

NCQ (Аппаратная Очерёдность Команд, Native Command Queuing ) – технология, разработанная для повышения производительности жёстких дисков с интерфейсом SATA II и выше.

Данные на жестком диске, располагаются по всей поверхности магнитной пластины и головке нужно время, чтобы найти расположение нужной дорожки и считать её.

Без NCQ :

Команды поступают на контроллёр диска, он даёт указание приводу головки на определённый участок, головка выполняет данную операцию и за ней следует следующая. То есть команды никак не сортируются и имеют приоритет только по времени поступления в контроллёр.

С поддержкой NCQ:

Команды поступают на контроллёр. Оценивается расположение данных на диске и приоритет команд. В зависимости от этого, после завершения очередной операции чтения/записи, головка перемещается к ближайшей дорожке, которую необходимо выполнить. Далее по мере появления новых команд в другой области, головка выполняет и ту операцию. На приоритет также влияет и размер считываемого/записываемого участка, чтобы не превысить лимит ожидания. Все эти операции происходят за доли секунд.


Сама технология призвана снизить время, затрачиваемое на перепозиционирование головки с дорожки на дорожку, оптимизируя перемещение до минимально возможного.

Что требуется для поддержки NCQ :

Жёсткий диск или твёрдотельный накопитель с поддержкой NCQ (все, что на интерфейсе Sata II (300) и выше).

AHCI контроллёр, встроенный в материнскую плату либо на отдельной плате расширения.

Драйвера, либо аппаратная поддержка операционной системой ( W 7, Vista , Free BSD 8.0 и выше, Linux Kernels ).

В каких условиях NCQ наиболее эффективна?

Для обычного домашнего компьютера, ждать увеличения производительности более 5% ждать не приходится, за тем исключением, если у вас ёмкий жёсткий диск с наполнением более 75%. Также, больший прирост производительности появляется, если одновременно работают несколько программ с активным обращением к диску или диск сильно фрагментирован. В данных случаях, прирост производительности может быть до 15% (при сильной фрагментации вплоть до 20%).

От использования NCQ они тоже выигрывают в скорости ввода/вывода и операций в секунду. Принцип работы немного другой и контроллёр опирается на скорость самого SSD и вычисляет какие операции лучше выполнить в первую очередь для поддержания скорости обмена данными на максимально возможном уровне. Также учитываются наиболее важные системные команды, которые должны быть выполнены в первую очередь, и распределяет чтение/запись на своё усмотрение, что позволяет получить от SSD ещё большую скорость отклика и количество операций в секунду ( IOPS ).

В большинстве случаев, для поддержки NCQ на твёрдотельных накопителях, необходимо установить драйвера, либо обновить BIOS или EFI .

Первоначальная реализация, которая была предназначена для PATA называлась TCQ (Tagged Command Queuing). Основным требованием, было использование протоколов ISA шины для операционной системы как основной, что увеличивало накладные расходы и ухудшало совместимость, а увеличение производительности было незначительным. Поэтому данная разработка не была поддержана производителями и в конце концов не получила распространение.

Когда на рынке появились первые жесткие диски, все они были подключены как PATA (Parallel AT Attachment), через широкий шлейф. Этот протокол также назывался IDE (Integrated Drive Electronics) . Однако в 2003 году начали поступать первые жесткие диски, которые использовали SATA (Serial AT Attachement). Вместе с SATA и появился новый протокол: AHCI (Advanced Host Controller Interface) . Этот новый протокол принес многочисленные улучшения производительности жестких дисков.

AHCI реализовал NCQ

Внедрение NCQ в жесткие диски SATA значительно улучшило их производительность. До их появления на жестких дисках использовалась система TCQ (Tagged Command Queuing). Однако этот протокол привел к непропорционально высокому потреблению процессора.

С NCQ - фишка заключалась в том, что жесткие диски перестали искать данные последовательно. Когда жесткий диск не использовал NCQ, то к данным обращались последовательно, что означало износ самого жесткого диска. И более длительное время ожидания, пока диск не завершит поиск. Но с NCQ доступ к данным осуществляется с помощью близости, что сводит к минимуму работу с диском. И существенно улучшая время поиска .

Функция Hot Swap

Еще одним преимуществом стала функция " Hot Swap" (Горячее отключение). Единственными устройствами хранения, которые можно было отключить в горячем режиме, были USB-накопители (которых в то время было не так много). Чтобы отключить жесткий диск, необходимо было выключить компьютер, чтобы иметь возможность физически отключить его. Если мы этого не сделаем, мы рискуем, что читающая головка упадет на внутреннюю пластину жесткого диска. С внедрением Hot Swap, пользователю просто нужно было сообщить операционной системе, что он хочет отключить это устройство. Именно тогда он отвечал за парковку считывающих головок и безопасное прерывание их работы. В то время, пользователь уже мог отключить соответствующий жесткий диск от отсека, где он был установлен.

AHCI

Поддержка протокола AHCI была реализована в Windows Vista . Однако, учитывая очень низкий успех этой операционной системы среди пользователей, большинство из нас были вынуждены использовать определенные драйверы для Windows XP. Эти драйверы должны были загружаться во время загрузки системы, обычно через дискету.

Windows 7 уже включала универсальный драйвер Microsoft. Тем не менее, в BIOS вы можете выбрать, какой протокол мы хотим использовать с нашими жесткими дисками. Но, если наш жесткий диск не очень старый и не имеет какой-либо несовместимости с AHCI, то лучше использовать этот протокол.

Привет, %username%! Ты наверняка давно знаешь, почему в UEFI нужно предпочесть AHCI, в чём подвох Secure Boot и почему MBR намного хуже, чем GPT. Если нет — самое время разобраться в вопросе, как выжать максимум скорости и стабильности из накопителя программными средствами.




Обратная совместимость технологий в ПК — безусловное благо. С её помощью пожилой процессор можно заставить работать в паре с оперативной памятью из «далёкого будущего», а новый накопитель без проблем приживается в древнем компьютере и делает его значительно быстрее даже с использованием старых версий интерфейса SATA.

И, если к legacy-коду можно относиться по-разному, то устаревшие протоколы и интерфейсы практически всегда уступают новым разработкам. Только вы об этом не узнаете, потому что новое железо в новом компьютере по умолчанию будет замедлено установками в пользу максимальной совместимости. Выясняем, какие настройки следует предпочесть, чтобы хорошему танцору новому накопителю не мешали устаревшие стандарты, и зачем в новых компьютерах «путаются под ногами» опции для устаревшего оборудования.

UEFI — не «альтернативно одарённый BIOS», а лучший метод инициализации оборудования

На «железном» уровне новшества во взаимодействии платформы ПК с накопителями предельно понятны: жёсткие диски наращивали плотность записи и увеличили количество пластин в 3,5-дюймовом форм-факторе и наполнили особо ёмкие модели гелием, чтобы диски стали работать стабильнее. Будущее HDD отныне зависит от темпов внедрения технологии черепичной магнитной записи или более радикальным изменениям (рывку в объёме накопителей) с термоассистируемой магнитной записью.

SSD? Сменили несколько типов памяти, перестали быть роскошью в домашних компьютерах, нарастили объём до сотен гигабайт. Выжали все соки из SATA-III, заполучили скорости PCI-E и наконец заимели компактный форм-фактор.



Накопитель Kingston DCP-1000 — до 1 100 000 IOPS на чтение и 200 000 IOPS на запись, например

Но быстродействие накопителей зависит не только от «железа», но и программной составляющей. И здесь самое время вспомнить о BIOS, который задержался на сцене, словно закостеневшие на старости лет эстрадные кумиры.

Сегодня в сознании трудящихся UEFI — это такая красочная альтернатива «биосу», с градиентами, красивыми меню, поддержкой мыши и, иногда, русифицированным интерфейсов. Тем удивительнее, что пёстрый EFI (Extensible Firmware Interface, тогда ещё без Unified в аббревиатуре) изначальном варианте был разработан Intel ещё в далёком 2003 году. И изначально его предлагали для серверных Itanium как более гибкий и быстрый интерфейс для загрузки ОС и инициализации/диагностики комплектующих. Уж больно много слабых мест было в древнем 16-битном BIOS с 1 Мбайт адресуемой памяти, поэтому замена напрашивалась сама собой. Как это обычно бывает в соревновании слоев абстракции и производительности железа, UEFI стал «тяжелее» и превратился в мини-операционную систему с драйверами и службами, но быстродействие и стабильность того стоили.

В массовые компьютеры UEFI пришёл в 2012-2013 гг., а вместе с ним в «предзагрузочном» интерфейсе появились приятные и не очень, нововведения. Начнём с функции-«защитницы» Windows 8, Secure Boot.

Secure Boot — многострадальная защита от «посредников» между ОС и UEFI

В инициативе по внедрению функции Secure Boot в UEFI версии 2.2 и выше разработчики руководствовалась благими намерениями, если вы понимаете, о чём мы. То, что первыми на вооружение эту функцию взяли Microsoft (чтобы обезопасить запуск Windows 8 и «придушить» активиторы-бутлоадеры) — другой разговор.

Некоторое время только Windows 8 и умела загружаться в режиме Secure Boot, а пользователям всех других ОС приходилось отключать функцию в BIOS UEFI, потому что интерфейс отказывался исполнять неподписанные файлы не подготовленных соответствующим образом систем.



Принцип работы Secure Boot

«Мякотка» заключалась в том, что все новые компьютеры по требованию Microsoft поставлялись с включенным Secure Boot, поэтому о новой функции (в не очень приятных обстоятельствах «падающей» системы) вскоре узнали все любители отличных от Win 8 операционных систем. А в некоторых случаях обновление Microsoft просто «по приколу» активировало Secure Boot в UEFI даже в Windows 7, которая после такой имплантации благополучно «падала» при следующей загрузке. Это ещё одна разновидность «романтических» обстоятельств знакомства с новой функцией в былые годы.



«Я те покажу, что такое безопасная загрузка!», — как бы говорит нам обновление KB3133977 и включает неподдерживаемый на Windows 7 Secure Boot в материнских платах ASUS

Справедливости ради, стоит отметить, что современные дистрибутивы GNU/Linux (Ubuntu, Fedora, Red Hat и openSUSE в числе первых) достаточно быстро обзавелись подписью для загрузки в Secure Boot, но в 2016 году с подачи Microsoft индустрии этот стандарт дважды, скажем так, аукнулся.

Первый раз — когда редмондцы «потеряли» мастер-ключ от Secure Boot и скомпрометировали защиту, за внедрение которой так активно выступали. Не штатный ключ, а именно мастер-ключ, с которым во всех выпущенных устройствах при активном Secure Boot загрузчик становится «голым и беззащитным», а злоумышленники могут легко и просто подменить операционную систему на этапе первоначальной загрузки. Нет повести печальнее на свете, чем повесть о «золотых ключах» и дебагерских инструментах в широком доступе.

А второй раз Microsoft наделала шума, когда упомянутый выше бэкдор начали было применять во благо как средство «джейлбрейка» планшетов под управлением Windows RT. Дело в том, что эксперимент Microsoft с ARM-системами закончился провалом, а крутые и дорогие (когда-то) планшеты Surface не получили даже поддержки UWP-приложений. То есть, неплохие с конструктивной точки зрения устройства стали заложниками «мёртвой» операционной системы. А другой операционной системы в планшете быть не могло, ведь Secure Boot на планшетах, по требованию Microsoft, был неотключаемым. После того, как упомянутый выше бэкдор оказался общественным достоянием, пользователи ARM-версий Surface получили на некоторое время возможность запустить неавторизованный загрузчик и установить альтернативную ОС. Но патч-латка за авторством Microsoft подоспел до того, как «еретики» успели что-то предпринять.



У Microsoft Surface RT был шанс заполучить альтернативную ОС. К сожалению, не сбылось.

Словом, Secure Boot уже подводила производителей и пользователей ПК, и, есть риск, что это произойдёт снова, поэтому тех, кто сомневается в её полезности, можно понять. Использовать ли «защищённую загрузку» или нет — вопрос открытый, как и в случае с подходом «паранойя vs установленный антивирус», если речь идёт о Windows. По умолчанию в старых матплатах не-брендовых ПК эта опция отключена, однако слабая защита всё же лучше, чем никакая.

Но бог с ними, с фичами безопасности, мы ведь здесь собрались ради настроек, которые ликвидируют «костыли» в работе накопителя? К ним и перейдём.

Устаревший и более медленный интерфейс по соображениям «кабы чего не вышло»

В списке устаревших технологий, которые гнездятся в новых матплатах ради совместимости со стандартами былых лет, неизменно фигурирует IDE (Integrated Drive Electronics) — режим контроллера накопителей, который не «ампутировали» из новых чипсетов только ради совместимости со старыми накопителями и ПО. В таком режиме накопители SATA 3.0 работают с быстродействием уровня своих PATA-предшественников.

А режим расширенного хост-контроллера (AHCI) даже в самых современных чипсетах отключен «до востребования». И напрасно, потому что только он сможет раскрыть потенциал современных накопителей при высокой нагрузке.

В былые времена загвоздка с использованием режима AHCI заключалась в том, что в операционных системах (Windows XP и Vista, по большей части) попросту не было драйверов для большинства AHCI-контроллеров в новых чипсетах, поэтому системы «падали в BSOD» сразу же после установки. Сегодня кулибины внедряют поддержку AHCI даже в эти две устаревшие системы, а уж Windows 7/8 и 10 поддерживают расширенный хост-контроллер в полной мере.



Накопитель в режиме последовательного чтения (IDE). Накопитель — Kingston SSD Now V+



Накопитель в режиме последовательного чтения (AHCI) (источник: dobreprogramy.pl)

От режима IDE AHCI отличает поддержка горячей замены накопителя (малополезно в домашнем ПК) и, что гораздо важнее, NQC. Native Command Queuing или «аппаратную установку очерёдности команд» часто считают новой разработкой для повышения быстродействия SSD, хотя на самом деле её разрабатывали ещё с учётом потенциала механических накопителей.

Поддержка NQC в режиме AHCI минимизирует движение головки в механических накопителях

NCQ «сортирует» команды при обращении к накопителю таким образом, чтобы минимизировать движения головки в HDD и как можно эффективнее использовать ячейки NAND в твердотельных накопителях. В случае с SSD режим AHCI важен ещё и для корректной работы TRIM и быстродействии на предельных для SATA-III скоростях (а в «потолок» SATA упираются даже недорогие накопители. Такие как Kingston UV400, например).



Режим AHCI жизненно важен для новых SATA-накопителей

Переключать режим работы контроллера желательно до установки операционной системы. Можно и после, но тогда придётся «заводить» AHCI с помощью нетрадиционной, понимаете ли, медицины. В любом случае, убедитесь, что ваши накопители используют для передачи данных современный интерфейс. Ведь гарантия того, что, например, Windows 98 сможет взаимодействовать с накопителем гораздо менее полезна, чем более высокое быстродействие в современных ОС и программах каждый день.

NTLDR is missing, если не используешь разметку GPT

Поддержка разметки GPT — ещё одна фича, которая стала повсеместно использоваться с приходом UEFI. Важная составляющая современных накопителей, и вот почему.

До прихода GUID Partition Table пользователям ПК приходилось довольствоваться архаичным методом размещения таблиц разделов — MBR или master boot record (главная загрузочная запись), стандарт образца 1983 года, ровесник DOS 2.0.

MBR — это такой сектор с загрузчиком операционной системы и информацией о логических дисках. Поддерживает работу с дисками объёмом до 2 Тбайт и только до четырёх основных разделов. Если 2-терабайтные HDD стали «бутылочным горлышком» в домашних ПК только недавно, то второй фактор породил трюки наподобие «расширенных разделов» ещё со стародавних времён.

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



Загрузчик — всё

А главное — GPT гораздо более отказоустойчив, потому что загрузчик и информация о разделах больше не хранятся «в одной корзине». Если MBR повреждён — ваш накопитель впадает в «беспамятство», а информацию с него придётся восстанавливать долго и нудно. GPT хранит копии этой информации в разных секторах диска и восстанавливает информацию, если она повреждена.

В ёмких HDD разметка GPT стала суровой необходимостью, а новые операционные системы используют её даже для накопителей ёмкостью много меньше 2 Тбайт. Разумный принцип организации и надёжность GPT однозначно перевешивают её недостатки, да и с поддержкой проблем нет ещё со времён Windows 8 (GNU/Linux тоже не обделены поддержкой), поэтому конвертировать диски из формата MBR в его последователя будет не лишним.

Файловые системы: вы уже готовы к ReFS, а она к вам — нет


Не форматируйте системный диск под Windows XP в FAT32! Если в ОС GNU/Linux файловые системы «цветут и пахнут» и внедряются без особой бюрократии, то монополии NTFS в накопителях под управлением Windows ничего не грозит. Но за прошедшие годы (без малого четверть века, если брать за отсчёт первую версию ФС) недостатки NTFS успели «набить оскомину» даже самой Microsoft, поэтому редмондцы разработали и, частично, внедрили преемника своего детища — ReFS (Resilient File System).

Файловая структура в ReFS

Дебютная версия «отказоустойчивой файловой системы» вышла в свет в бета-версиях Windows 8 и её серверных аналогах. Её будущее в домашних ПК пока туманно, тем более, в роли системного раздела, но ключевые наработки Microsoft в этом направлении известны уже сегодня. Среди них:

• Поддержка длинных имен. До 32768 символов в пути вместо 255, как это было в NTFS
• Устойчивость к перебоям в питании устройства. Данные и результаты изменений не будут повреждены, потому что файловая система оперирует метаданными и восстанавливает информацию в случае их повреждения. При любых операциях файловая система сначала создаёт новую копию метаданных в свободном пространстве, и только потом, в случае успеха, переводит ссылку со старой области метаданных на новую. Вот вам и сохранность файлов без журналирования.
• Избыточность хранения данных для большего ресурса накопителя.
• Более высокая скорость работы за счёт пониженной фрагментации.

ReFS ещё недостаточно отполирована для повсеместного внедрения, но если откуда-то и стоит ждать новшеств в методе хранения и оперирования файлами в Windows, то только отсюда.

Новое — значит лучшее?

Рекомендация выбирать самые новые протоколы и технологии из доступных была бы слишком наивной — всегда стоит взвешивать за и против, прежде чем расставлять галочки в UEFI или операционной системе. Но всё же стоит помнить о том, что в апгрейд старого компьютера — дело рук самих владельцев этого компьютера. ПК с многолетней выдержкой очень редко способен сконфигурировать новое железо правильным образом. А это значит, что после модернизации будет не лишним проверить, в каком режиме работает новая «железка» — хотя бы среди тех вариантов, о которых мы говорили сегодня. Заставляйте ваши SSD работать «на все деньги» при любом удобном случае!



Всякую новую вещь нужно уметь правильно использовать

Правильная конфигурация BIOS/UEFI и операционной системы — это хорошо, а когда она управляет новым быстрым железом — ещё лучше! Для всех любителей совмещать программную прокачку комплектующих с непосредственно апгрейдом мы дарим скидку 10% на SSD HyperX и память DDR4 в магазинах DNS и 10% скидки на накопители HyperX Fury и память DDR3 в Ситилинк! Акция действует с 21 марта по 4 апреля, это отличная возможность сделать свой компьютер быстрее и сэкономить.

А ещё мы рады сообщить, что вскоре обладателем нашей новейшей флагманской гарнитуры с объёмным звуком станет подписчик Kingston. Поэтому, если вы ещё не подписаны, нужно скорее исправлять ситуацию. :) Мы выберем победителя случайным образом и огласим имя никнейм счастливчика 7 апреля. Не упустите шанс заполучить звучание кинематографического уровня для своего компьютера!


Подписывайтесь и оставайтесь с нами — будет интересно!

Для получения дополнительной информации о продукции Kingston и HyperX обращайтесь на официальный сайт компании. В выборе своего комплекта HyperX поможет страничка с наглядным пособием.

Читайте также: