Сегментация жесткого диска это
Для работы с жестким диском его для начала необходимо как-то разметить, чтобы операционная система могла понять в какие области диска можно записывать информацию. Поскольку жесткие диски имеют большой объем, их пространство обычно разбивают на несколько частей — разделов диска. Каждому такому разделу может быть присвоена своя буква логического диска (для систем семейства Windows) и работать с ним можно, как будто это независимый диск в системе.
Способов разбиения дисков на разделы на сегодняшний день существует два. Первый способ — использовать MBR. Этот способ применялся еще чуть ли не с появления жестких дисков и работает с любыми операционными системами. Второй способ — использовать новую систему разметки — GPT. Этот способ поддерживается только современными операционными системами, поскольку он еще относительно молод.
Структура MBR
До недавнего времени структура MBR использовалась на всех персональных компьютерах для того, чтобы можно было разделить один большой физический жесткий диск (HDD) на несколько логических частей — разделы диска (partition). В настоящее время MBR активно вытесняется новой структурой разделения дисков на разделы — GPT (GUID Partition Table). Однако MBR используется еще довольно широко, так что посмотрим что она из себя представляет.
MBR всегда находится в первом секторе жесткого диска. При загрузке компьютера, BIOS считывает этот сектор с диска в память по адресу 0000:7C00h и передает ему управление.
Итак, первая секция структуры MBR — это секция с исполняемым кодом, который и будет руководить дальнейшей загрузкой. Размер этой секции может быть максимум 440 байт. Далее идут 4 байта, отведенные на идентификацию диска. В операционных системах, где идентификация не используется, это место может занимать исполняемый код. То же самое касается и последующих 2 байт.
Начиная со смещения 01BEh находится сама таблица разделов жесткого диска. Таблица состоит из 4 записей (по одной на каждый возможный раздел диска) размером 16 байт.
Структура записи для одного раздела:
Первым байтом в этой структуре является признак активности раздела. Этот признак определяет с какого раздела следует продолжить загрузку. Может быть только один активный раздел, иначе загрузка продолжена не будет.
Следующие три байта — это так называемые CHS-координаты первого сектора раздела.
По смещению 04h находится код типа раздела. Именно по этому типу можно определить что находится в данном разделе, какая файловая система на нем и т.п. Список зарезервированных типов разделов можно посмотреть, например, в википедии по ссылке Типы разделов.
После типа раздела идут 3 байта, определяющие CHS-координаты последнего сектора раздела.
CHS-координаты сектора расшифровываются как Cylinder Head Sector и соответственно обозначают номер цилиндра (дорожки), номер головки (поверхности) и номер сектора. Цилиндры и головки нумеруются с нуля, сектор нумеруется с единицы. Таким образом CHS=0/0/1 означает первый сектор на нулевом цилиндре на нулевой головке. Именно здесь находится сектор MBR.
Все разделы диска, за исключением первого, обычно начинаются с нулевой головки и первого сектора какого-либо цилиндра. То есть их адрес будет N/0/1. Первый раздел диска начинается с головки 1, то есть по адресу 0/1/1. Это все из-за того, что на нулевой головке место уже занято сектором MBR. Таким образом, между сектором MBR и началом первого раздела всегда есть дополнителььные неиспользуемые 62 сектора. Некоторые загрузчики ОС используют их для своих нужд.
Интересен формат хранения номера цилиндра и сектора в структуре записи раздела. Номер цилиндра и номер сектора делят между собой два байта, но не поровну, а как 10:6. То есть на номер сектора приходится младшие 6 бит младшего байта, что позволяет задавать номера секторов от 1 до 63. А на номер цилиндра отведено 10 бит — 8 бит старшего байта и оставшиеся 2 бита от младшего байта: «CCCCCCCC CCSSSSSS», причем в младшем байте находятся старшие биты номера цилиндра.
Проблема с CHS-координатами состоит в том, что с помощью такой записи можно адресовать максимум 8 Гб диска. В эпоху DOS это было приемлемо, однако довольно скоро этого перестало хватать. Для решения этой проблемы была разработана система адресации LBA (Logical Block Addressing), которая использовала плоскую 32-битную нумерацию секторов диска. Это позволило адресовать диски размером до 2Тб. Позже разрядность LBA увеличили до 48 бит, однако MBR эти изменения не затронули. В нем по-прежнему осталась 32-битная адресация секторов.
Итак, в настоящее время повсеместно используется LBA-адресация для секторов на диске и в структуре записи раздела адрес его первого сектора прописывается по смещению 08h, а размер раздела — по смещению 0Ch.
Для дисков размером до 8Гб (когда адресация по CHS еще возможна) поля структуры с CHS-координатами и LBA-адресации должны соответствовать друг другу по значению (корректно конвертироваться из одного формата в другой). У дисков размером более 8Гб значения всех трех байт CHS-координат должны быть равны FFh (для головки допускается также значение FEh).
В конце структуры MBR всегда находится сигнатура AA55h. Она в какой-то степени позволяет проверить, что сектор MBR не поврежден и содержит необходимые данные.
Расширенные разделы
Разделы, отмеченные в таблице типом 05h и 0Fh, это так называемые расширенные разделы. С их помощью можно создавать больше разделов на диске, чем это позволяет MBR. На самом деле расширенных разделов несколько больше, например есть разделы с типами C5h, 15h, 1Fh, 91h, 9Bh, 85h. В основном все эти типы разделов использовались в свое время различными операционными системами (такими как например OS/2, DR-DOS, FreeDOS) с одной и той же целью — увеличить количество разделов на диске. Однако со временем различные форматы отпали и остались только разделы с типами 05h и 0Fh. Единственное исключение — это тип 85h. Он до сих пор может использоваться в Linux для формирования второй цепочки логических дисков, скрытых от других операционных систем. Разделы с типом 05h используются для дисков менее 8Гб (где еще возможна адресация через CHS), а тип 0Fh используется для дисков больше 8Гб (и используется LBA-адресация).
В первом секторе расширенного раздела находится структура EBR (Extended Boot Record). Она во многом схожа со структурой MBR, но имеет следующие отличия:
- В EBR нет исполняемого кода. Некоторые загрузчики могут его туда записывать, но обычно это место заполнено нулями
- Сигнатуры диска и два неиспользуемых байта должны быть заполнены нулями
- В таблице разделов могут быть заполнены только две первых записи. Остальные две записи должны быть заполнены нулями
В отличие от MBR, где позволяется создавать не более четырёх разделов, структура EBR позволяет организовать список логических разделов, ограниченный лишь размером раздела-контейнера (того самого, который с типом 05h или 0Fh). Для организации такого списка используется следующий формат записей: первая запись в таблице разделов EBR указывает на логический раздел, связанный с данным EBR, а вторая запись указывает на следующий в списке раздел EBR. Если данный логический раздел является последним в списке, то вторая запись в таблице разделов EBR должна быть заполнена нулями.
Формат записей разделов в EBR аналогичен формату записи в структуре MBR, однако логически немного отличается.
Признак активности раздела для разделов структуры EBR всегда будет 0, так как загрузка осуществлялась только с основных разделов диска. Координаты CHS, с которых начинается раздел используются, если не задействована LBA-адресация, также как и в структуре MBR.
А вот поля, где в режиме LBA-адресации должны находиться номер начального сектора и количество секторов раздела, в структуре EBR используются несколько иначе.
Для первой записи таблицы разделов EBR в поле начального сектора раздела (смещение 08h) записывается расстояние в секторах между текущим сектором EBR и началом логического раздела, на который ссылается запись. В поле количества секторов раздела (смещение 0Ch) в этом случае пишется размер этого логического раздела в секторах.
Для второй записи таблицы разделов EBR в поле начального сектора раздела записывается расстояние между сектором самой первой EBR и сектором следующей EBR в списке. В поле количества секторов раздела в этом случае пишется размер области диска от сектора этой следующей структуры EBR и до конца логического раздела, относящегося к этой структуре.
Таким образом, первая запись таблицы разделов описывает как найти, и какой размер занимает текущий логический раздел, а вторая запись описывает как найти, и какой размер занимает следующий EBR в списке, вместе со своим разделом.
Структура GPT
В современных компьютерах на смену BIOS пришла новая спецификация UEFI, а вместе с ней и новое устройство разделов на жестком диске — GUID Partition Table (GPT). В этой структуре были учтены все недостатки и ограничения, накладываемые MBR, и разработана она была с большим запасом на будущее.
Кроме того, в отличие от MBR, структура GPT хранит на диске две своих копии, одну в начале диска, а другую в конце. Таким образом, в случае повреждения основной структуры, будет возможность восстановить ее из сохраненной копии.
Рассмотрим теперь устройство структуры GPT подробнее. Вся структура GPT на жестком диске состоит из 6 частей:
LBA-адрес | Размер (секторов) | Назначение |
LBA 0 | 1 | Защитный MBR-сектор |
LBA 1 | 1 | Первичный GPT-заголовок |
LBA 2 | 32 | Таблица разделов диска |
LBA 34 | NN | Содержимое разделов диска |
LBA -34 | 32 | Копия таблицы разделов диска |
LBA -2 | 1 | Копия GPT-заголовка |
Защитный MBR-сектор
Первый сектор на диске (с адресом LBA 0) — это все тот же MBR-сектор. Он оставлен для совместимости со старым программным обеспечением и предназначен для защиты GPT-структуры от случайных повреждений при работе программ, которым про GPT ничего не известно. Для таких программ структура разделов будет выглядеть как один раздел, занимающий все место на жестком диске.
Структура этого сектора ничем не отличается от обычного сектора MBR. В его таблице разделов дожна быть создана единственная запись с типом раздела 0xEE. Раздел должен начинаться с адреса LBA 1 и иметь размер 0xFFFFFFFF. В полях для CHS-адресации раздел соответственно должен начинаться с адреса 0/0/2 (сектор 1 занят под саму MBR) и иметь конечный CHS-адрес FF/FF/FF. Признак активного раздела должен иметь значение 0 (неактивный).
При работе компьютера с UEFI, данный MBR-сектор просто игнорируется и никакой код в нем также не выполняется.
Первичный GPT-заголовок
Этот заголовочный сектор содержит в себе данные о всех LBA-адресах, использующихся для разметки диска на разделы.
Структура GPT-заголовка:
Смещение (байт) | Размер поля (байт) | Пример заполнения | Название и описание поля |
0x00 | 8 байт | 45 46 49 20 50 41 52 54 | Сигнатура заголовка. Используется для идентификации всех EFI-совместимых GPT-заголовков. Должно содержать значение 45 46 49 20 50 41 52 54, что в виде текста расшифровывается как "EFI PART". |
0x08 | 4 байта | 00 00 01 00 | Версия формата заголовка (не спецификации UEFI). Сейчас используется версия заголовка 1.0 |
0x0C | 4 байта | 5C 00 00 00 | Размер заголовка GPT в байтах. Имеет значение 0x5C (92 байта) |
0x10 | 4 байта | 27 6D 9F C9 | Контрольная сумма GPT-заголовка (по адресам от 0x00 до 0x5C). Алгоритм контрольной суммы — CRC32. При подсчёте контрольной суммы начальное значение этого поля принимается равным нулю. |
0x14 | 4 байта | 00 00 00 00 | Зарезервировано. Должно иметь значение 0 |
0x18 | 8 байт | 01 00 00 00 00 00 00 00 | Адрес сектора, содержащего первичный GPT-заголовок. Всегда имеет значение LBA 1. |
0x20 | 8 байт | 37 C8 11 01 00 00 00 00 | Адрес сектора, содержащего копию GPT-заголовка. Всегда имеет значение адреса последнего сектора на диске. |
0x28 | 8 байт | 22 00 00 00 00 00 00 00 | Адрес сектора с которого начинаются разделы на диске. Иными словами — адрес первого раздела диска |
0x30 | 8 байт | 17 C8 11 01 00 00 00 00 | Адрес последнего сектора диска, отведенного под разделы |
0x38 | 16 байт | 00 A2 DA 98 9F 79 C0 01 A1 F4 04 62 2F D5 EC 6D | GUID диска. Содержит уникальный идентификатор, выданный диску и GPT-заголовку при разметке |
0x48 | 8 байт | 02 00 00 00 00 00 00 00 | Адрес начала таблицы разделов |
0x50 | 4 байта | 80 00 00 00 | Максимальное число разделов, которое может содержать таблица |
0x54 | 4 байта | 80 00 00 00 | Размер записи для раздела |
0x58 | 4 байта | 27 C3 F3 85 | Контрольная сумма таблицы разделов. Алгоритм контрольной суммы — CRC32 |
0x5C | 420 байт | 0 | Зарезервировано. Должно быть заполнено нулями |
Система UEFI проверяет корректность GPT-заголовка, используя контрольный суммы, вычисляемые по алгоритму CRC32. Если первичный заголовок поврежден, то проверяется контрольная сумма копии заголовка. Если контрольная сумма копии заголовка правильная, то эта копия используется для восстановления информации в первичном заголовке. Восстановление также происходит и в обратную сторону — если первичный заголовок корректный, а копия неверна, то копия восстанавливается по данным из первичного заголовка. Если же обе копии заголовка повреждены, то диск становится недоступным для работы.
У таблицы разделов дополнительно существует своя контрольная сумма, которая записывается в заголовке по смещению 0x58. При изменении данных в таблице разделов, эта сумма рассчитывается заново и обновляется в первичном заголовке и в его копии, а затем рассчитывается и обновляется контрольная сумма самих GPT-заголовков.
Таблица разделов диска
Следующей частью структуры GPT является собственно таблица разделов. В настоящее время операционные системы Windows и Linux используют одинаковый формат таблицы разделов — максимум 128 разделов, на каждую запись раздела выделяется по 128 байт, соответственно вся таблица разделов займет 128*128=16384 байт, или 32 сектора диска.
Недавно мы оттестировали новые модели SCSI-дисков Seagate Cheetah со скоростью вращения 10 000 и 15 000 об./мин — Cheetah 10K.7 и Cheetah 15K.4. Испытания показали, что даже с текущими серийными версиями firmware эти диски имеют достаточно скромную производительность, уступающую не только производительности прямых аналогов от Maxtor (Atlas 10K V и Atlas 15K II соответственно), но даже своих предшественников с соответствующей скоростью вращения. И если при серверных нагрузках новые диски Seagate Cheetah вели себя еще более или менее приемлемо (в плане быстродействия), то в приложениях более потребительского характера за редким исключением их скорость была неприлично скромна.
Пытаясь разобраться, в чем причина, и можно ли программными мерами (то есть модернизацией firmware) повысить производительность этих накопителей (а то, что это в принципе, возможно, мы, в общем-то, и не сомневаемся :)) мы провели специальное исследование влияния сегментирования кэш-памяти дисков на их быстродействие в тех или иных приложениях. Суть его достаточно проста.
Дело в том, что бесплатная и доступная для свободного скачивания с сайта производителя утилита Seagate SeaTools Enterprise
позволяет не только получать подробную информацию об установленных в системе SCSI дисках,
проводить их необходимую диагностику и даже обновлять firmware
(если такое оказалось в ваших руках ;)),
но также осуществлять над SCSI-дисками Seagate некоторые дополнительные «продвинутые» (Advanced) операции: включать и выключать кэширование чтения и записи буфером диска, переключаться между тремя (!) режимами поиска в целях оптимизировать потребление/нагрев и шумность работы накопителей и так далее. Но наиболее интересной для нас в текущем контексте является возможность переключать новейшие SCSI-диски Seagate между двумя разными моделями (политиками) кэширования — Desktop Mode и Server Mode. Этот пункт в меню SeaTools носит название Performance Mode (PM) и может принимать два значения — On (Desktop Mode) и Off (Server Mode).
Отличия между этими двумя режимами чисто программные — в случае Desktop Mode кэш-память жесткого диска разбивается на фиксированное число сегментов постоянного (одинакового) объема и далее они используются для кэширования обращений при чтении и записи. Причем, в отдельном пункте меню пользователь даже может сам назначать количество сегментов (управлять сегментированием кэша): например, вместо дефолтных 32 сегментов проставить другое значение (при этом объем каждого сегмента пропорционально уменьшится).
В случае Server Mode сегменты буфера (кэша диска) могут динамически (пере)назначаться, меняя при этом свой размер и количество. Микропроцессор (и микропрограмма) диска сами динамически оптимизируют количество (и емкость) сегментов кэш-памяти в зависимости от поступающих для исполнения на диск команд.
SCSI-диски Seagate поставляются с предустановкой PM=Off (то есть установленные в Server Mode) и, честно говоря, мне непонятно, почему разработчики в данном случае использовали такую терминологию — ведь, по идее, название «перформанс мода» больше подходит для серверных применений, тем более если она еще и более интеллектуальна (обеспечивает динамическую сегментацию), то есть преследует цель повысить таким образом производительность диска. Возможно, разработчики Seagate создав эту фичу и сами поняли, что простейшая фиксированная сегментация пока в среднем более эффективна в текущих приложениях и отразили это в данном названии? :) Но тогда напрашивается вывод, что интеллектуальная динамическая сегментация, предлагаемая в данном случае Seagate, не доведена как следует до ума. Впрочем, это я уже забегаю вперед и начинаю комментировать результаты тестов… :)
Так или иначе, но для тех пользователей, кто предпочитает использовать SCSI-диски для решения типичных задач настольного компьютера, существует возможность переключить этот диск в более характерный для таких применений режим кэширования «Desktop» (из дефолтного «Server»).
Данное исследование имеет не только «чисто академический» характер (как может показаться менее пытливому читателю), но, напротив, представляет немалый практический интерес. Во-первых, для, собственно, дисков Seagate Cheetah — позволяя пользователю выбрать наиболее подходящий ему режим эксплуатации этих накопителей. А во-вторых, влияние количества и емкости сегментов на производительность в тех или иных приложениях широко используется и при создании обычных настольных ATA-дисков, а они, как мы знаем, пока в большинстве своем имеют как раз буфер 8 Мбайт, как и у исследуемых нами объектов. Поэтому выявив закономерности влияния сегментации для «Чит», мы можем распространить их и на настольные накопители.
Участники испытаний
В данном тестировании участвовали две модели дисков Seagate: Cheetah 15K.4 (модель ST3146854LW емкостью 147 Гбайт) и Cheetah 10K.7 (модель ST373207LC емкостью 73 Гбайт). Для сравнения мы использовали свежие модели Maxtor Atlas 10K V и Atlas 15K II, а также диск Seagate Cheetah 10K.6 (в дефолтных режимах работы). Подробную информацию о данных накопителях вы можете найти по соответствующим линкам.
Методика тестирования скоростных показателей
- Процессор Intel Pentium 4 3.0C
- Материнская плата Gigabyte GA-8KNXP Ultra-64 на чипсете Intel E7210 (i875P с южным мостом Hance Rapids 6300ESB с шиной PCI-X)
- Системная память 2×256 Мбайт DDR400 (тайминги 2,5-3-3-6)
- Контроллер Ultra320 SCSI Adaptec AIC-7902B на шине PCI64
- Системный жесткий диск Maxtor 6E040L0
- Блок питания Zalman ZM400A-APF, 400 ватт
- Корпус Arbyte YY-W201BK-A
Другие детали по методике тестирования совпадают с описанными ранее, например, здесь. Диски Seagate Cheetah 15K.4 и 10K.7 тестировались с версией firmware 0003.
Результаты тестов физических параметров
Анализировать абсолютные показатели и графики скорости линейного чтения в данном случае смысла нет (они идентичны для разных мод сегментирования), поэтому переходим сразу к скорости работы интерфейса Ultra320 SCSI. Диски Seagate здесь на высоте, заметно опережая Maxtor Atlas. Различия между Server и Desktop (32 сегмента) модами здесь тоже практически отсутствуют.
А вот по измеренному среднему времени доступа начинаются сюрпризы: использование Destop Mode существенно увеличивает среднее время доступа при чтении для обоих дисков Seagate — на 0,4-0,5 мс для Cheetah 15K.4 и на 0,8 мс для Cheetah 10K.7. То есть примерно на 10% для каждого! Во второй части мы попробуем разобраться, почему так происходит, а пока лишь констатируем сей не очень приятный для мощных SCSI-накопителей факт. Впрочем, как мы увидим ниже, это отнюдь не мешает им повысить свою производительность во многих приложениях при использовании Desktop Mode. Таким образом, динамическое сегментирование Seagate приносит явные дивиденды в плане скорости поиска.
Об эффективности работы алгоритмов отложенной записи firmware диска и кэширования записываемых данных в буфере накопителя можно попытаться судить по тому, как падает среднее, измеренное операционной системой, время доступа при записи относительно чтения при включенном write-back кэшировании накопителя. Есть даже мнение, что такой тест позволяет судить об уровне сегментирования кэш-памяти диска — чем больше сегментов, тем меньше будет эффективное среднее время при записи.
Для выяснения этого мы используем результаты теста C'T H2benchW. (Разумеется, не следует думать, что average write access time на этой диаграмме реально отражает данную физическую характеристику накопителей! Это лишь некий программно измеряемый при помощи теста C'T H2benchW параметр, по которому можно судить об эффективности кэширования записи в буфере диска. Реальное заявленное производителем среднее время доступа при записи для Cheetah 10K.7, например, составляет 5,3+3,0=8,3 мс)
Оказывается, что если при чтении мы наблюдали заметный рост времени доступа, то при записи изменений практически нет. В общем, это вполне предсказуемо, если исходить из того, что измеряемый параметр при записи отражает не физическую характеристику накопителя, а эффективность кэширования. Но с другой стороны, это говорит о том, что в рамках данной модели обращений к диску в режиме Server Mоde не происходит заметных изменений сегментирования кэш-памяти по сравнению с постоянными «десктопными» 32 сегментами. В целом исследуемые диски Seagate и в Desktop Mode уступают по этим двум параметрам как конкурентам от Maxtor, так и предшественнице Cheetah 10K.6.
Быстродействие в приложениях
Переходим к тестам производительности в приложениях. И первым делом, попробуем выяснить, как хорошо диски оптимизированы для многопотоковой работы (тесты в программе NBench 2.4, где файлы размером 100 Мбайт записываются на диск и читаются с него несколькими одновременными потоками).
Эффективность алгоритмов многопотоковой отложенной записи жестких дисков при работе операционной системы с файлами в данном случае практически не зависит от используемого режима сегментирования кэша дисков Seagate (а практическая идентичность показания лишний раз свидетельствует в пользу надежности использования данного теста ;)). К сожалению, снова приходится констатировать сильное отставание последних моделей Seagate от конкурентов и даже некоторых предшественников.
При многопотоковом чтении, однако, ситуация для дисков Seagate кардинально меняется: налицо великолепная (иного слова я просто не подберу для более чем сорокапроцентного улучшения!) оптимизация динамического сегментирования кэш-памяти под подобные задачи. И снова возникает резонный вопрос — тот ли режим назвали Performance? ;) Лидерство новых дисков Seagate здесь не вызывает никаких сомнений.
Теперь о WinBench Disk WinMark 99. По идее, Desktop Mode именно здесь должна показать свои преимущества над Server Mode. И мы не ошиблись — Cheetah 10K.7 заметно (до 30%) прибавила в скорости от использования Performance Mode, хотя для Cheetah 15K.4 прибавка оказалась гомеопатической — лишь полтора-три процента.
Впрочем, это касается только офисной (Business) производительности, тогда как в профессиональной (High-End) производительности теста WinBench 99 картина немного хуже — Cheetah 10K.7 прибавила лишь около 20%, а Cheetah 15K.4 даже напротив — уступила несколько процентов в Performance Mode. В целом же можно констатировать, что постоянное сегментирование кэш-памяти хотя и подняло скорость последнему SCSI-десятитысячнику Seagate, но все же не помогло диску Cheetah 10K.7 догнать в этих тестах свою предшественницу Cheetah 10K.6.
Более свежие комплексные «трековые» тесты оценки «настольной» производительности дисков в пакетах PCMakr04 и C'T H2BenchW в целом демонстрируют похожие на WinBench 99 закономерности.
В Futuremark PCMark04 при использовании Desktop Mode Cheetah 10K.7 прибавила 34%, но продолжает катастрофически отставать от остальных фигурантов.
И хотя в H2benchW прирост ее производительности оказался еще больше — почти 60% (!) — догнать Читу 10K.6 она все же не в состоянии. :( Что же касается Cheetah 15K.4, то использование Desktop Mоde в обоих этих тестах приносит ей крайне невысокие дивиденды (от 1 до 6%) и общую ситуацию практически не меняет.
По скорости работы дисков с временным файлом программы Adobe Photoshop мы наблюдаем полную индифферентность Cheetah 15K.4 к изменению политики сегментирования кэш-памяти, а Cheetah 10K.7 ускоряется всего на 6% при использовании Desktop Mode с 32-мя постоянными сегментами. В целом по комплексу «настольных» тестов можно констатировать, что применение Desktop Mode для Cheetah 15K.4 лишено особого смысла, а с точки зрения многопотокового чтения даже противопоказано (Server Mode в последнем случае существенно эффективнее), хотя для Cheetah 10K.7 использование Desktop Mode, напротив, может принести определенную и весьма заметную пользу (опять же — кроме многопотокового чтения).
Тесты в Intel Iometer
Переходим к задачам, более характерным для профилей использования SCSI-накопителей — работе различных серверов (DataBase, File Server, Web Server) и рабочей станции (Workstation) по соответствующим паттернам в программе Intel IOmeter версии 2003.5.10.
Во всех трех серверных паттернах Cheetah 15K.4 работает чуточку быстрее, если используется динамическое сегментирование кэша (Server Mode), хотя разницу с Desktop Mode здесь никак нельзя назвать существенной (единицы процентов). Что и подтверждается на усредненной диаграмме (см. ниже).
С другой стороны, для Cheetah 10K.7 в серверных паттернах использование Server Mode ведет к заметному ускорению работы (в среднем — на 13%).
Причем преимущество Server Mode над Desktop Mode в данном случае почти не зависит от типа серверного паттерна и глубины очереди запросов.
Впрочем, все равно Cheetah 10K.7 отстает здесь от своей предшественницы и, тем более, от Maxtor Atlas 10K V.
По итогам тестов на серверных нагрузках можно заключить, что использование Server Mode предпочтительно для обоих дисков Seagate (и особенно, для Cheetah 10K.7), в случае пятнадцатитысячника особой разницы с Desktop Mode, как и во многих настольных паттернах, мы здесь не наблюдаем.
Что касается паттерна «рабочая станция», тот здесь картина немного меняется — для Cheetah 15K.4 явно предпочтительнее использование Server Mode (особенно на большой глубине очереди), а для Cheetah 10K.7 почти никакой разницы от использования того или иного режима сегментирования кэш-памяти мы не наблюдаем.
Теперь — паттерны случайного чтения и записи больших и мелких файлов.
При случайном чтении крупных файлов для Cheetah 15K.4 чуть более предпочтительно использование Server Mode, тогда как для Cheetah 10K.7, напротив, двукратное (. ) преимущество в быстродействии обеспечивает именно Desktop Mode! И 10K.7, наконец-то, обходит свою предшественницу 10K.6 и конкурента от Maxtor. Интересно, что этот результат прямо противоположен явному превосходству Server Mode при многопотоковом чтении, но на то эти задачи и различны — одна использует чтение по случайным адресам, а другая читает несколько одновременных последовательных потоков.
При случайной записи крупных файлов, однако, разницы между модами почти нет — лишь для Cheetah 10K.7 «настольный» режим немного предпочтительнее на большой очереди.
Чтение мелких файлов по случайным адресам в чем-то сродни измерению среднего времени доступа при чтении, а в нем, как мы помним, заметно лучше вела себя Server Mode. И действительно, для Cheetah 15K.4 наблюдается аналогичная картина — Server Mode явно лучше десктопной. Однако на этом сходство заканчивается и для Cheetah 10K.7, напротив, (как и при чтении крупных файлов) почти двукратное преимущество имеет Desktop Mode! Хотя в этот раз она и не позволяет диску догнать конкурентов. Невольно напрашивается вывод, что в данном случае программисты Seagate упустили что-то важное при написании firmware для Cheetah 10K.7, позволив серверной моде (то есть динамическому сегментированию буфера) показать столь неважные результаты, хотя все предпосылки для лучшей работы у нее были. Другой вывод — динамическая сегментация у Cheetah 15K.4 и 10K.7, видимо, имеет какие-то достаточно существенные различия.
Что касается записи мелких файлов по случайным адресам в пределах всего диска, то здесь картина сходна с таковой для чтения мелких файлов. С той разницей, что для Cheetah 15K.4 оба режима практически равноценны, а для ее младшей сестрицы отрыв Desktop Mode от серверной не столь велик.
Копирование крупных файлов — вотчина Maxtor Atlas 10K V. Использование Desktop Mode безразлично для пятнадцатитысячника Seagate и немного полезно для десятитысячника, хотя Читу 10K.6 он по-прежнему догнать не способен.
Примерно то же — при копировании мелких файлов, хотя здесь уже на больших очередях запросов отрыв Desktop Mode от серверной увеличивается.
По результатам геометрического усреднения данных для случайного чтения, записи и копирования крупных и мелких файлов получаем, что повторяется картина, отмеченная нами ранее в десктопных «трековых» тестах, а также в WinBench Disk WinMark 99 — новая Seagate Cheetah 10K.7 способна выиграть в среднем до 30% быстродействия при использовании Desktop Mode вместо Server Mode, но даже это не позволяет ей догнать по производительности свою предшественницу Cheetah 10K.6. Что касается Cheetah 15K.4, то здесь оба режима сегментирования буфера дают примерно одинаковые результаты, не позволяя накопителю заметно прибавить в скорости.
При имитации дефрагментации мы наблюдаем примерное повторение этой картины и очень слабые результаты для Seagate Cheetah 10K.7, тогда как диски Maxtor Atlas лидируют со значительным отрывом.
Наконец, в паттерне потоковых чтения-записи (50/50) крупными и мелкими блоками картина в целом та же: Desktop Mоde весьма полезна для Cheetah 10K.7 и практически бесполезна для Cheetah 15K.4.
Промежуточные выводы
Подытоживая тесты первой части этого обзора, хочется отметить, что использование новых накопителей Seagate Cheetah в режиме «Desktop» (при фиксированном сегментировании по умолчанию на 32 сегмента) вместо дефолтного «Server» с динамическим сегментированием способно немного поднять производительность дисков в ряде задач, более характерных для настольного компьютера. Причем, эта прибавка порой может достигать 30-100% (!) в зависимости от типа задачи и модели диска, хотя в среднем она оценивается величиной 30%, что, согласитесь, тоже неплохо. Среди таких задач — рутинная работа настольного ПК (тесты WinBench, PCmark, H2bench), чтение и копирование файлов, дефрагментация. При этом в серверных приложениях производительность накопителей почти не падает (если и падает, то незначительно). Впрочем, заметный выигрыш от использования Desktop Mode мы смогли наблюдать только на диске Cheetah 10K.7, тогда как ее старшей сестрице Cheetah 15K.4 оказалось почти все равно, в каком из режимов работать над настольными приложениями.
Среди тех задач, где явную фору имеют более прогрессивные алгоритмы динамической сегментации кэш-памяти накопителя (а я бы именно ее назвал «перформанс модой») — многопотоковое чтение, множественные случайные обращения к диску (чтение очень мелких файлов, где важно среднее время поиска), серверные приложения. И именно здесь Cheetah 15K.4 проявила бОльшую заинтересованность, чем при «настольной» работе.
Но к сожалению, даже эта «программная фича» Seagate (Performance Mode) оказалась неспособна поднять весьма скромную производительность новых SCSI-дисков Seagate до уровня конкурентов (в среднем по совокупности тестов, хотя в отдельных «номинациях» конкуренция все же наблюдается), а у диска Cheetah 10K.7 — хотя бы до уровня его предшественницы Cheetah 10K.6. Впрочем, напомним, что в «положительном» арсенале новых Seagate Cheetah остаются высокая надежность, раскрученная годами «высокая марка», а также весьма низкое энергопотребление-тепловыделение (а это один из реально привлекательных факторов) и более тихая (то есть малошумная) работа, чем у традиционных SCSI-десятитысячников.
В первой части данного обзора мы познакомились с режимом Performance Mode у SCSI-дисков Seagate Cheetah со скоростью вращения 10 000 и 15 000 об./мин — Cheetah 10K.7 и Cheetah 15K.4. Напомню, что утилита Seagate SeaTools Enterprise позволяет пользователю управлять политикой кэширования и, в частности, переключать новейшие SCSI-диски Seagate между двумя разными моделями кэширования — Desktop Mode и Server Mode. Этот пункт в меню SeaTools носит название Performance Mode (PM) и может принимать два значения — On (Desktop Mode) и Off (Server Mode). Отличия между этими двумя режимами чисто программные — в случае Desktop Mode кэш-память жесткого диска разбивается на фиксированное число сегментов постоянного (одинакового) объема и далее они используются для кэширования обращений при чтении и записи. Причем, в отдельном пункте меню пользователь даже может сам назначать количество сегментов (управлять сегментированием кэша): например, вместо дефолтных 32 сегментов проставить другое значение (при этом объем каждого сегмента пропорционально уменьшится).
В случае же Server Mode сегменты буфера (кэша диска) могут динамически (пере)назначаться, меняя при этом свой размер и количество. Микропроцессор (и микропрограмма) диска сами динамически оптимизируют количество (и емкость) сегментов кэш-памяти в зависимости от поступающих для исполнения на диск команд.
Тогда мы смогли выяснить, что использование новых накопителей Seagate Cheetah в режиме «Desktop» (при фиксированном сегментировании по умолчанию — на 32 сегмента) вместо дефолтного «Server» с динамическим сегментированием способно немного поднять производительность дисков в ряде задач, более характерных для настольного компьютера или медиа-серверов. Причем, эта прибавка порой может достигать 30-100% (!) в зависимости от типа задачи и модели диска, хотя в среднем она оценивается величиной 30%, что, согласитесь, тоже неплохо. Среди таких задач — рутинная работа настольного ПК (тесты WinBench, PCmark, H2bench), чтение и копирование файлов, дефрагментация. При этом в чисто серверных приложениях производительность накопителей почти не падает (если и падает, то незначительно). Впрочем, заметный выигрыш от использования Desktop Mode мы смогли наблюдать только на диске Cheetah 10K.7, тогда как ее старшей сестрице Cheetah 15K.4 оказалось почти все равно, в каком из режимов работать над настольными приложениями.
Пытаясь разобраться дальше, как влияет сегментирование кэш-памяти этих жестких дисков на производительность в различных приложениях и какие режимы сегментирования (какое количество сегментов памяти) более выгодно при выполнении тех или иных задач, я исследовал влияние количества сегментов кэш-памяти на производительность диска Seagate Cheetah 15K.4 в широком диапазоне значений — от 4 до 128 сегментов (4, 8, 16, 32, 64 и 128). Результаты этих исследований и предлагаются вашему вниманию в этой части обзора. Подчеркну, что данные результаты интересны не только сугубо для этой модели дисков (или SCSI-дисков Seagate в целом) — сегментирование кэш-памяти и выбор количества сегментов — это одно из основных направлений оптимизации firmware, в том числе, настольных дисков с интерфейсом ATA, которые сейчас также оснащаются преимущественно буфером 8 Мбайт. Поэтому описанные в данной статье результаты производительности накопителя в различных задачах в зависимости от сегментирования его кэш-памяти имеют отношение и к индустрии настольных ATA-накопителей. А поскольку методика испытаний была описана в первой части, переходим непосредственно к самим результатам.
Впрочем, прежде, чем перейти к обсуждению результатов, взглянем чуть подробнее на устройство и работу сегментов кэш-памяти диска Seagate Cheetah 15K.4, чтобы лучше понимать, о чем идет речь. Из восьми мегабайт для собственно кэш-памяти (то есть для кэширующих операций) здесь доступно 7077 Кбайт (остальное — служебная область). Эта область делится на логические сегменты (Mode Select Page 08h, byte 13), которые используются для чтения и записи данных (для осуществления функций упреждающего чтения с пластин и отложенной записи на поверхность диска). Для обращения к данным на магнитных пластинах сегменты используют именно логическую адресацию блоков накопителя. Диски этой серии поддерживают максимум 64 сегмента кэш-памяти, причем длина каждого сегмента равна целому числу секторов диска. Объем доступной кэш-памяти, по всей видимости, распределяется поровну между сегментами, то есть если сегментов, скажем, 32, то объем каждого сегмента равен примерно 220 Кбайт. При динамической сегментации (в режиме PM=off) количество сегментов может меняться винчестером автоматически в зависимости от потока команд от хоста.
Приложения для серверов и настольных компьютеров требуют различных операций кэширования от дисков для обеспечения оптимальной производительности, поэтому сложно обеспечить единую конфигурацию для наилучшего выполнения этих задач. По мнению Seagate, для «настольных» приложений требуется сконфигурировать кэш-память так, чтобы быстро отвечать на повторяющиеся запросы большого количества небольших сегментов данных без задержек на упреждающее чтение смежных сегментов. В серверных задачах, напротив, требуется так сконфигурировать кэш, чтобы обеспечить поступление больших объемов последовательных данных в неповторяющихся запросах. В этом случае более важна способность кэш-памяти хранить больше данных из смежных сегментов при упреждающем чтении. Поэтому для Desktop Mode производитель рекомендует использовать 32 сегмента (в ранних версиях Cheetah использовались 16 сегментов), а для Server Mode адаптивное количество сегментов стартует всего с трех на весь кэш, хотя в процессе работы может и увеличиваться. Мы в своих экспериментах по поводу влияния количества сегментов на производительность в различных приложениях ограничимся диапазоном от 4 сегментов до 64 сегментов, а в качестве проверки «прогоним» диск также при 128 сегментах, установленных в программе SeaTools Enterprise (программа при этом не сообщает, что данное количество сегментов в этом диске недопустимо).
Результаты тестов физических параметров
Графики скорости линейного чтения при разном количестве сегментов кэш-памяти приводить никакого смысла нет — они одинаковы. А вот по измеренной тестами скорости работы интерфейса Ultra320 SCSI можно наблюдать весьма любопытную картину: при 64 сегментах некоторые программы начинают неправильно определять скорость работы интерфейса, снижая ее более чем на порядок.
По измеренному среднему времени доступа отличия между различным количеством сегментов кэш-памяти становятся более заметны — по мере снижения сегментации среднее измеренной под Windows время доступа при чтении немного растет, а существенно лучшие показания наблюдаются в режиме PM=off, хотя утверждать при этом, что количество сегментов очень мало или, наоборот, очень велико, на основании этих данных сложно. Возможно, что диск в данном случае просто начитает игнорировать префетч при чтении, чтобы исключить дополнительных задержки.
Об эффективности работы алгоритмов отложенной записи firmware диска и кэширования записываемых данных в буфере накопителя можно попытаться судить по тому, как падает среднее измеренное операционной системой время доступа при записи относительно чтения при включенном write-back кэшировании накопителя (оно в наших тестах было всегда включено). Для этого мы обычно используем результаты теста C'T H2benchW, но в этот раз дополним картину и тестом в программе IOmeter, паттерны чтения и записи для которой использовали стопроцентно случайный доступ блоками по 512 байт с единичной глубиной очереди запросов. (Разумеется, не следует думать, что average write access time на двух диаграммах ниже реально отражает данную физическую характеристику накопителей! Это лишь некий программно измеряемый при помощи теста параметр, по которому можно судить об эффективности кэширования записи в буфере диска. Реальное заявленное производителем среднее время доступа при записи для Cheetah 15K.4 составляет 4,0+2,0=6,0 мс). Кстати, предвидя вопросы, замечу, что в данном случае (то есть когда в диске разрешена отложенная запись) накопитель рапортует хосту об успешном завершении команды записи (статус GOOD) сразу, как только они записаны в кэш-память, а не непоседственно на магнитный носитель. Этим и обусловлено меньшее значение измеренного извне average write access time, чем для аналогичного параметра при чтении.
По результатам этих тестов налицо ясная зависимость эффективности кэширования случайной записи мелких блоков данных от количества сегментов кэш-памяти — чем больше сегментов, тем лучше. При четырех сегментах эффективность резко падает и среднее время доступа при записи возрастает почти до значений при чтении. А в «серверной моде» число сегментов в данном случае, очевидно, близко к 32. Случаи 64 и "128" сегментов полностью идентичны, что подтверждает программное ограничение на уровне 64 сегментов сверху.
Интересно, что тест IOmeter в простейших паттернах на случайный доступ блоками 512 байт дает совершенно такие же значения при записи, что и тест C'T H2BenchW (с точностью буквально до сотых долей миллисекунды), тогда как при чтении IOmeter показал несколько завышенный результат во всем диапазоне сегментирования — возможно, разница в 0,1-0,19 мс с другими тестами на время случайного доступа при чтении обусловлена какими-то «внутренними» причинами для IOmeter (или же размером блока 512 байт вместо 0 байт, как требуется в идеале для таких измерений). Впрочем, результаты «по чтению» у IOmeter практически совпадают с таковыми для дискового теста программы AIDA32.
Быстродействие в приложениях
Переходим к тестам производительности накопителей в приложениях. И первым делом, попробуем выяснить, как хорошо диски оптимизированы для многопотоковой работы. Для этого я традиционно использую тесты в программе NBench 2.4, где файлы размером 100 Мбайт записываются на диск и читаются с него несколькими одновременными потоками.
Данная диаграмма позволяет нам судить об эффективности алгоритмов многопотоковой отложенной записи жестких дисков в реальных (а не синтетических, как было на диаграмме со средним временем доступа) условиях при работе операционной системы с файлами. Лидерство обоих SCSI-дисков Maxtor при записи несколькими одновременными потоками не вызывает сомнений, однако у Читы мы уже наблюдаем некий оптимум в районе между 8 и 16 сегментами, тогда как при более высоких и более низких значениях скорость диска на данных задачах падает. Для Server Mode число сегментов, очевидно, равно 32 (с хорошей точностью :)), а "128" сегментов — это, на самом деле, 64.
При многопотоковом чтении ситуация для дисков Seagate явно улучшается по сравнению с дисками Maxtor. Что же касается влияния сегментации, то, как и при записи, мы наблюдаем некий оптимум ближе к 8 сегментам (при записи он был ближе к 16 сегментам), а при очень высоком сегментировании (64) скорость диска существенно понижается (как и при записи). Отрадно, что Server Mode тут «отслеживает базар» хоста и меняет сегментирование с 32 при записи на ~8 при чтении.
Теперь посмотрим, как диски ведут себя в «преклонных», но до сих пор популярных тестах Disk WinMark 99 из пакета WinBench 99. Напомню, что мы проводим эти тесты не только для «начала», но и для «середины» (по объему) физического носителя для двух файловых систем, а на диаграммах приведены усредненные результаты. Безусловно, данные тесты не являются «профильными» для SCSI-накопителей, и мы приводя тут их результаты скорее отдаем дань уважения самому тесту и тем, кто привык судить о скорости диска по тестам WinBench 99. В качестве «утешения» заметим, что эти тесты с определенной долей достоверности покажут нам, какова производительность этих enterprise-накопителей при выполнении задач, более характерных для настольного компьютера.
Очевидно, что оптимум сегментирования есть и здесь, причем при малом количестве сегментов диск смотрится невыразительно, а при 32 сегментах — наилучшим образом (возможно, именно поэтому разработчики Seagate «сместили» дефолтную настройку Desktop Mode с 16 до 32 сегментов). Впрочем, для Server Mode в офисных (Business) задачах сегментирование не совсем оптимально, тогда как для профессиональной (High-End) производительности сегментирование более чем соптимизировано, заметно обгоняя даже оптимальную «постоянную» сегментацию. Видимо, именно в процессе выполнения теста она меняется в зависимости от потока команд и за счет этого получается выигрыш в общей производительности.
К сожалению, такой оптимизации «по ходу теста» не наблюдается для более свежих «трековых» комплексных тесты оценки «настольной» производительности дисков в пакетах PCMakr04 и C'T H2BenchW.
На обоих (а точнее — на 10 различных) «треках активности» интеллект Server Mode заметно уступает оптимальной постоянной сегментации, которая для PCmark04 равна примерно 8 сегментам, а для H2benchW — 16 сегментам.
Для обоих этих тестов 4 сегмента кэш-памяти оказывается очень нежелательным, да и 64 тоже, и сложно сказать, к чему больше тяготеет в своем выборе Server Mode в данном случае.
В противовес этим, безусловно, все же синтетическим (хотя и очень похожим на реальность) тестам — совершенно «реальный» тест скорости работы дисков с временным файлом программы Adobe Photoshop. Здесь ситуация гораздо позрачнее — чем больше сегментов, тем лучше! И Server Mode это почти «уловила», воспользовавшить 32 сегментами для своей работы (хотя 64 было бы еще чуточку лучше).
Тесты в Intel Iometer
Переходим к задачам, более характерным для профилей использования SCSI-накопителей — работе различных серверов (DataBase, File Server, Web Server) и рабочей станции (Workstation) по соответствующим паттернам в программе Intel IOmeter версии 2003.5.10.
С имитацией сервера базы данных успешнее всех справляется Maxtor, а для Seagate выгоднее всего использование Server Mode, хотя по сути последняя очень близка к 32 постоянным сегментам (объемом примерно по 220 кбайт каждый). Меньшее или большее сегментирование в данном случае оказывается хуже. Впрочем, это паттерн слишком прост по виду запросов — посмотрим, что будет для более комплексных паттернов.
При имитации файлового сервера лидирует снова адаптивная сегментация, хотя отставание от нее 16 постоянных сегментов ничтожно (32 сегмента тут чуть хуже, хотя тоже вполне достоны). При малом сегментировании наблюдается ухудшение на большой очереди команд, а при слишком большом (64) любая очередь вообще противопоказана — видимо, в этом случае слишком малым оказывается размер секторов кэша (менее 111 Кбайт, то есть всего 220 блоков на носителе), чтобы эффективно кэшировать приемлемые по размеру объемы данных.
Наконец, для Web-сервера мы видим даже более занятную картину — при НЕединичной очереди команд Server Mode равноценна любому уровню сегментирования, кроме 64, хотя на единичной она чуть лучше всех.
В результате геометрического усреднения показанных выше серверных нагрузок по паттернам и очередям запросов (без весовых коэффициентов) получаем, что для подобных задач адаптивное сегментирование лучше всего, хотя 32 постоянных сегмента отстают незначительно, да и 16 сегментов тоже смотрятся в целом неплохо. В общем, выбор Seagate вполне можно понять.
Что касается паттерна «рабочая станция», тот здесь Server Mode явно лучше всех.
А оптимум для постоянной сегментации находится на уровне 16 сегментов.
Теперь — наши паттерны для IOmeter, более близкие по назначению настольным ПК, хотя определенно показательные и для enterprise-накопителей, поскольку и в «глубоко профессиональных» системах жесткие диски львиную долю времени считывают и записывают большие и маленькие файлы, а также иногда копируют файлы. А поскольку характер обращений в данных паттернах в данных паттернах в тесте IOmeter (по случайным адресам в пределах всего объема диска) более характерен именно для систем серверного класса, то и важность этих паттернов для исследуемых дисков выше.
Чтение крупных файлов снова лучше дается для Server Mode, за исключением непонятного провала на QD=4. Однако небольшое количество крупных сегментов явно предпочтительнее для диска на этих операциях (что, в принципе, предсказуемо и отлично согласуется с результатами для многопотокового чтения файлов, см. выше).
Думаю, именно это использует Server Mode для выбора адаптивного режима — уж очень похожи их графики.
Копирование крупных файлов — явная неудача Server Mode! Здесь явно выгоднее сегментирование с уровнем 16 (это оптимум, поскольку 8 и 32 хуже на очереди 4).
По результатам геометрического усреднения данных для случайного чтения, записи и копирования крупных и мелких файлов получаем, что наилучший в среднем результат дает постоянное сегментирование с уровнем всего 4 сегмента на кэш (то есть размеры сегментов более 1,5 Мбайт!), тогда как 8 и 16 сегментов примерно равноценны и почти не отстали от 4 сегментов, а вот 64 сегмента явно противопоказаны. Адаптивная Server Mode в среднем лишь немного уступила постоянной сегментации — проигрыш одного процента вряд ли можно считать заметным.
Остается отметить, что при имитации дефрагментации мы наблюдаем примерное равенство всех уровней постоянной сегментации и небольшое преимущество Server Mode (на тот же 1%).
А в паттерне потоковых чтения-записи крупными и мелкими блоками слегка выгоднее использование малого количества сегментов, хотя снова отличия в быстродействии конфигураций кэш-памяти здесь, как ни странно, гомеопатичны.
Выводы
Как уже говорилось в статье о режимах эксплуатации , оборудование делится на две основные категории: домашне-офисное, куда можно отнести десктоп (desktop) c мобильными дисками (mobile – для ноутбуков и переносные 2,5”) и энтерпрайс (enterprise), где располагаются диски для серверов и систем хранения данных (СХД).
Что их отличает в первую очередь? – наработка на отказ и как следствие – гарантия. Кто-то возразит, что для домашних дисков зачастую заявляют время наработки куда больше, чем для серверных, например, 2 млн. часов против 1.6 млн. часов. Нет, тут всё верно, просто это совсем не те часы, которые представляет обычный пользователь, где 2 млн. часов это 230 лет работы.
Во-первых, это «сферические часы», т.е. если мы возьмём 1000 дисков и включим их все одновременно, то через 2000 часов эксплуатационного времени один из них скорее всего выйдет из строя. Грубо-говоря это некоторый коэффициент брака, не относящийся к десяткам лет непрерывной эксплуатации одного единственного диска. Что такое эксплуатационное время? Это ещё одна тонкость, связанная с режимом эксплуатации.
Во-вторых, режимы эксплуатации: для домашнего диска, как и для другого оборудования, как вы помните это режим 8/5, т.е. 40 часов в неделю. И именно эти недели целиком считаются в общей наработке домашних дисков, а не именно часы непосредственной работы. Т.е. те самые 2 млн. часов наработки на отказ для домашнего сегмента, это когда берётся 1000 дисков, включается в работу на 12 недель, при этом всего на 8 часов в день по 5 дней в неделю и к концу 12-ой недели один из дисков скорее всего выйдет из строя. Итого дисками будет наработано фактически всего 480 часов, или 20 полных суток.
Пугающе мало? – И даже это не полные ограничения на эксплуатацию домашних дисков: каждый час сверх нормы каждого диска отнимает уже по 2 часа от изначальных 2 млн. Но и на этом не заканчиваются все ограничения – кроме эксплуатационного времени для домашних дисков предусматривается ещё и домашний сценарий использования: 15% записи и 35% чтения. 35+15=50, а где ещё 50? – А считается, что в домашнем сегменте половину машинного времени диск простаивает. На самом же деле в офисном сценарии использования диск простаивает вообще до 80% времени.
А что с серверными (или энтерпрайз) дисками? - А у них всё нормально - их 1,6 млн. часов это 1000 дисков работающих непрерывно и круглосуточно в течении 1600 часов и где-то на 10-ой неделе возможен выход из строя одного из дисков. При этом ещё и сценарий использования предполагает 30% записи и 70% чтения, т.е. занимается полностью все машинное время и диск не простаивает.
Итого: домашние 2 млн. часов это почти в три раза меньше серверных 1.6 млн. часов
Также и различается гарантия на диски: домашние, как правило, обеспечиваются 2-х летней гарантией (иногда 3-х летней), а серверные – 5-ти летней.
В чём отличие домашних дисков от мобильных? – по эксплуатационным параметрам различия отсутствуют: тот же режим 8/5, те-же 15% записи и 35% чтения. Более ли менее значимые отличия - это экономия энергии и быстродействие. Если домашние диски переходят в режим ожидания (паркуют голову и останавливают мотор) в среднем после 5 минут простоя, то мобильные диски через 1 минуту.
Это средние значения, есть и домашние диски, засыпающие через 2 минуты простоя, есть и мобильные, бодрствующие до 3-4 минут. Это поведение в отсутствии дополнительных команд от контроллера на материнской плате или операционной системы. По быстродействию же у многих мобильных дисков, из-за их размеров и расположения в ноутбуках заложено замедление обработки операций при нагреве.
Сделано это специально: во-первых, это ограничивает выделение тепла, что критично для остальных компонентов ноутбука, во-вторых это уменьшает шанс возникновения ошибки при записи в условиях возможной вибрации, поскольку нагрев попутно ведёт и к расширению материалов, а т.к. диск собран из разного рода компонентов – все они расширяются не синхронно, приводя к микро деформациям.
А через сколько засыпают серверные диски? – А серверные диски засыпают сугубо по сигналу контроллера или операционной системы, при отсутствии таковых мотор не останавливается.
Повышенное время наработки на отказ, готовность к эксплуатации 24/7, гарантия на 5 лет, всегда готовность к работе – может тогда лучше и в домашние/офисные компьютеры ставить энтерпрайз, а не домашние диски?
Нет, энтерепрайз сегмент не всегда подходит для домашнего использования и вот по каким причинам:
Домашние диски почти вдвое дешевле за тот же объем.
По сценарию нагрузок и типичных требований домашние диски обходятся без обдува, прекрасно функционируя даже в условиях малого закрытого пространства или компактного корпуса. Энтерпрайз диски, даже аналогичные по скоростям домашним: 7200 об/мин требуют обдув в среднем одним 120 мм кулером на 2-4 диска.
В угоду скорости работы уровень шума это последнее, что принимается во внимание у энтерпрайз сегмента. Если домашние диски ведут себя вполне беззвучно в условиях офиса, то серверные вполне способны напоминать о своём присутствии. И если домашний диск начинает греметь – это один из возможных симптомов его скорого выхода из строя, то для серверного диска это обычное поведение, которое только может добавлять нервозности.
- Поведение при ошибке.
Пожалуй, самый важный пункт различий между домашним и серверным диском. При возникновении ошибки записи домашний диск сам пытается решить проблему - пробует записать это сектор опять, записывает данные в резервную область, пропускает сектор, при этом делая запись в s.m.a.r.t.
Серверный диск же оповещает и запрашивает контроллер на дальнейшие действия вставая в режим ожидания, при этом так же делая пометку в s.m.a.r.t. Т.е. в некоторых случаях возникновение ошибки может приводить к зависанию домашнего или офисного компьютера, т.к. установленные в них контроллеры не рассчитаны на работу с одиночными серверными дисками. При активации функции RAID на плате или силами операционной системы этот функционал поддерживается даже на домашних платах, но в серверных он поддерживается всегда, хотя там крайне редко диск работает в одиночку.
Подводя итог первой части: каждый диск хорош там, где он и должен работать.
Читайте также: