Поддержка секторов размером 4 кб что это
Сектор жёсткого диска имеет следующую структуру:
- Интервал: промежуток между секторами.
- Код синхронизации: метка синхронизации, обозначающая начало сектора и позволяющая синхронизировать работу диска.
- Метка адреса: метка, содержащая данные для идентификации номера и расположения сектора. В ней также хранится информация о состоянии сектора.
- Область данных: в этой области хранятся данные пользователя.
- Область исправления ошибок: в этой области хранятся коды исправления ошибок, с помощью которых исправляются и восстанавливаются данные, которые могли быть повреждены во время чтения или записи. Этот низкоуровневый формат используется в нашей отрасли уже многие годы. Однако в связи с ростом емкости жестких дисков размер сектора неизбежно становится конструктивным ограничением для дальнейшего повышения емкости дисков и эффективности исправления ошибок. К примеру, если соотнести размер сектора с емкостью устаревших и современных дисков, то можно увидеть, что разрешение сектора многократно уменьшилось
Переход к секторам размером 4 КБ (новый формат)
В индустрии хранения данных уже несколько лет ведутся совместные работы над переходом к секторам большего размера. Компания Seagate вместе с партнерами проводит масштабные работы в этом направлении уже более пяти лет В декабре 2009 года в результате совместных усилий IDEMA был создан и утвержден новый формат Advanced Format. Это название стало официальным для стандарта секторов размером 4 КБ. Кроме того, все производители жестких дисков договорились начать поставки новых моделей дисков этого формата для настольных и переносных ПК к январю 2011 года. Как ожидается, жесткие диски формата Advanced Format начнут поступать на рынок раньше этого времени. Компания Western Digital начала поставки жестких дисков нового формата в декабре 2009 года; компания Seagate уже некоторое время поставляет жесткие диски с секторами большого размера OEM-производителям, а также комплектует ими устройства, производимые под собственной маркой, прежде всего внешние жесткие диски с интерфейсом USB, такие как Seagate® FreeAgent®.
Перспективные преимущества секторов размером 4 КБ
Поскольку производители жестких дисков договорились перейти к новому формату секторов к январю 2011 года, остальным участникам отрасли ИТ необходимо заранее подготовиться к этому переходу, чтобы избежать возможных негативных последствий. В краткосрочном периоде потребители не ощутят заметного эффекта, если говорить о быстром росте емкости жестких дисков. Однако переход к секторам размером 4 КБ, несомненно, позволит быстрее добиться большей плотности записи и увеличения емкости жестких дисков, а также надежного исправления ошибок.
Повышение эффективности формата за счет сокращения пространства, занимаемого кодом исправления ошибок
Структура традиционного сектора размером 512 байт такова, что для каждого 512-байтного сектора на диск дополнительно записываются 50 байт, содержащие код исправления ошибок, и еще 15 байт с интервалом, кодом синхронизации и меткой адреса. В результате эффективность секторного формата составляет примерно 88 процентов (512/(512 65))
В новом формате отводится столько же места под интервал, код синхронизации и метку адреса, а код исправления ошибок увеличен до 100 байт. В результате эффективность секторного формата увеличивается до 97 процентов (4096/(4096 115)), то есть почти на 10 процентов.
Запись небольших объемов данных
В современных приложениях данные, такие как документы, изображения и потоковое видео, обрабатываются блоками размером значительно больше 512 байт. Поэтому жесткий диск легко может хранить запросы на запись этих блоков в кэш-памяти до тех пор, пока не будет накоплено достаточное количество блоков размером 512 байт для записи сектора размером 4 КБ. Если логическая структура разделов диска соответствует его физической структуре, то жесткий диск может легко сопоставить сектора размером 512 байт сектору размером 4 КБ без ущерба для производительности. Однако есть низкоуровневые процессы, которые могут заставить жесткий диск работать с «карликовыми» блоками, независимо от соответствия логической и физической структуры. Это происходит в редких случаях, когда компьютер отправляет жесткому диску отдельные запросы, размер которых меньше 4 КБ. Как правило, такие запросы отправляет операционная система при работе с файловой системой, журналировании и выполнении других подобных низкоуровневых задач. В общем случае такие запросы встречаются нечасто и не оказывают существенного влияния на производительность. Однако проектировщикам ПО рекомендуется пересмотреть подобные процессы, чтобы добиться оптимальной производительности, поскольку переход к секторам размером 4 КБ уже «не за горами».
Подготовка и организация перехода к секторам размером 4 КБ
Теперь, когда понятны преимущества перехода к секторам размером 4 КБ, а также возможное влияние такого перехода на производительность, настало время определить наилучший способ организации процесса перехода. Правильнее всего обсуждать эту тему в контексте двух самых популярных современных операционных систем: Windows и Linux.
Организация перехода к секторам размером 4 КБ в ОС Windows
Самый главный вопрос организации перехода к секторам размером 4 КБ — это вопрос соответствия физической и логической структуры, уже рассмотренный выше. Диски нового формата хорошо работают в состоянии «Выравнивание 0», в котором физическая и логическая начальные точки совпадают. Состояние выравнивания возникает в тот момент, когда создаются разделы жесткого диска. Разделы создаются программным обеспечением, которое можно разделить на две категории:
- Версии ОС Windows.
- Специальные средства разбиения жесткого диска на разделы.
В случае когда разделы созданы ОС Windows, есть три версии этой ОС, которые можно обсуждать: Windows XP, Windows Vista и Windows 7. Компания Microsoft участвовала в обсуждении и планировании перехода к большему размеру сектора. В результате в ее продуктах появилась поддержка секторов размером 4 КБ, начиная с Windows Vista с пакетом обновления Service Pack 1. Программные продукты, создающие разделы с «Выравниванием 0» (разделы, хорошо работающие с новым форматом), называются продуктами с поддержкой секторов размером 4 КБ. В таблице отражена ситуация для текущих поколений ОС Microsoft Windows.
| Версия операционной системы | Поддержка секторов размером 4 КБ | Результаты |
| Windows XP | Нет | Создается первичный раздел в состоянии «Выравнивание 1» (без выравнивания) |
| Windows Vista — без пакета обновления Service Pack 1 | Нет | Поддерживаются сектора большого размера, но разделы создаются неправильно (без выравнивания) |
| Windows Vista — с пакетом обновления Service Pack 1 или более поздней версии | Да | Создаются разделы в состоянии «Выравнивание 0» (с выравниванием) |
| Windows 7 | Да | Создаются разделы в состоянии «Выравнивание 0» (с выравниванием) |
Очевидно, что новые компьютеры с последними версиями Windows лучше всего подготовлены к использованию жестких дисков нового формата. Однако на компьютерах, на которых используется Windows XP или Windows Vista без пакета обновления Service Pack 1, есть значительный риск потери производительности при использовании разделов, созданных операционной системой.
Помимо риска несоответствия логической и физической структуры диска при использовании старых версий ОС Windows, существует несколько средств, которыми активно пользуются сборщики систем, OEM-производители, реселлеры и компании, оказывающие услуги управления ИТ-инфраструктурой. Использование этих средств также может стать причиной несоответствия между логической и физической структурой диска. Фактически чаще можно встретить разделы, созданные с помощью этих средств, чем с помощью ОС Windows. Поэтому велик риск создания разделов, в которых логическая структура не соответствует физической, что приводит к потере производительности при использовании дисков с размером сектора 4 КБ. Еще больше эта проблема осложняется тем, что сегодня поставляемые вместе с компьютерами жесткие диски обычно содержат несколько разделов. Это означает, что каждый из разделов такого диска должен быть создан с помощью программы с поддержкой секторов размером 4 КБ, чтобы обеспечить соответствие между логической и физической структурой, а значит, и высокую производительность. На рис. 10 показаны возможные результаты создания нескольких разделов на жестком диске с помощью программы, не обладающей поддержкой секторов размером 4 КБ.
Разделы с несоответствием между логической и физической структурой
Есть три способа избежать несоответствия между логической и физической структурой диска или исправить это несоответствие, чтобы предупредить потери производительности.
- Использовать новую версию ОС Windows или приобрести средство разбиения на разделы с поддержкой секторов размером 4 КБ.
- Выровнять разделы жесткого диска с помощью специального средства.
- Положиться на поставщика жесткого диска в части производительности, независимо от состояния структуры диска.
Использование версии Windows с поддержкой секторов размером 4 КБ — это самый простой и короткий путь обеспечить соответствие между логической и физической структурой диска. Поставщики других средств разбиения на разделы могут сообщить вам, существуют ли версии их средств с поддержкой секторов размером 4 КБ. Если такие версии есть, переходите на них, чтобы предупредить возникновение проблем.
Некоторые производители жестких дисков предлагают специальные средства, позволяющие проверить структуру разделов на жестком диске и изменить выравнивание разделов при необходимости. Для этого нужно потратить дополнительное время и выполнить дополнительные действия при сборке или обновлении компьютера.
Наконец, производители жестких дисков будут разрабатывать все более совершенные способы работы с разделами, в которых есть несоответствие между логической и физической структурой. Эти способы помогут избежать потерь производительности.
По мере увеличения популярности нового формата жестких дисков будут применяться все три способа, и каждый из них поможет потребителям добиться наибольшего полезного эффекта и избежать потерь производительности.
Жесткий диск WD10EARS с сектором 4 КБ.
Подготовка к эксплуатации в Linux.
Исходя из специфики работы автору приходится регулярно приобретать различные новые жесткие диски, как правило для сохранения посекторных копий с неисправных накопителей.
На этот раз для этих целей был приобретен терабайтный винчестер фирмы Western Digital, модель WD10EARS-00Y5B1. В винчестере используется технология «Advanced Format», что в переводе на русский означает новый внутренний (низкоуровневый) формат с размером сектора 4096 байт (4 КБ) вместо устоявшегося за десятки лет стандартного 512-байтного сектора.
Теоретически, никаких особых нюансов в работе с этим винчестером быть не должно, т. к. он представляется как обычный НЖМД со стандартным сектором 512 Байт (разумеется, это эмулируется самим накопителем), что видно из его идентификационных данных, обозначенных на наклейке — LBA: 1953525168. Подверждение этому получаем и (забегая немного наперед) программно:
# hdparm -I /dev/sdb | grep LBA48
LBA48 user addressable sectors: 1953525168
# hdparm -I /dev/sdb | grep Sector\ size
Logical/Physical Sector size: 512 bytes
Тем не менее, производитель почему-то настойчиво акцентирует внимание на предварительной подготовке накопителя для работы в «устаревших» системах, о чем пишет на крышке самого накопителя и дополнительно дублирует на наклейке на упаковочном кульке. Причем явно указана только Windows XP. Для остальных ОС «drive is ready for use as is», что можно интерпретировать как «подготовки не требует», так и «ешьте, что дают 🙂 ».
Разумеется, мы зададимся вопросом, есть ли особенности в работе этого HDD в Linux, раз ни прямо ни косвенно об этом не упоминается.
Исследования ведутся на IBM-PC совместимом компьютере, собранном на базе материнской платы ECS KV2 Extreme (чипсет VIA K8T880+VT8237R с дополнительным контроллером PATA+SATA на SiS 180, к которому и подключается испытуемый винчестер), процессор Athlon64 3700+, 1ГБ ОЗУ. Установлен частично русифицированный Slackware-12.1, проапгрейжен hdparm с 8.6 до 9.27.
Как издавна на Руси повелось, перво-наперво ориентируемся в пространстве:
Диск /dev/sda: 1000.2 ГБ, 1000204886016 байт
255 heads, 63 sectors/track, 121601 cylinders
Units = цилиндры of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000945ef
Устр-во Загр Начало Конец Блоки Id Система
/dev/sda1 1 127 1020096 b W95 FAT32
/dev/sda2 128 5099 39937590 83 Linux
/dev/sda3 * 5100 10071 39937590 7 HPFS/NTFS
/dev/sda4 10072 121601 895864725 7 HPFS/NTFS
Диск /dev/sdb: 1000.2 ГБ, 1000204886016 байт
255 heads, 63 sectors/track, 121601 cylinders
Units = цилиндры of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
На диске /dev/sdb отсутствует верная таблица разделов
Уточняем устройство для экспериментов:
# hdparm -i /dev/sdb | grep Model
Model=WDC WD10EARS-00Y5B1, FwRev=80.00A80, SerialNo=WD-WCAV55974950
Тест скорости чтения:
# hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 302 MB in 3.01 seconds = 100.48 MB/sec
Тест скорости чтения посредством dd:
# dd if=/dev/sdb of=/dev/null bs=128K count=20000
20000+0 записей считано
20000+0 записей написано
скопировано 2621440000 байт (2,6 GB), 24,372 c, 108 MB/c
Тест скорости записи посредством dd:
# dd if=/dev/zero of=/dev/sdb bs=128K count=20000
20000+0 записей считано
20000+0 записей написано
скопировано 2621440000 байт (2,6 GB), 24,2364 c, 108 MB/c
Теперь создаём один основной раздел на всю «поляну»:
# fdisk /dev/sdb
Команда (m для справки): n
Действие команды
e расширенный
p основной раздел (1-4)
p
Номер раздела (1-4): 1
Первый цилиндр (1-121601, по умолчанию 1):
Используется значение по умолчанию 1
Последний цилиндр или +size или +sizeM или +sizeK (1-121601, по умолчанию 121601):
Используется значение по умолчанию 121601
Команда (m для справки): p
Диск /dev/sdb: 1000.2 ГБ, 1000204886016 байт
255 heads, 63 sectors/track, 121601 cylinders
Units = цилиндры of 16065 * 512 = 8225280 bytes
Disk identifier: 0x15f317bf
Устр-во Загр Начало Конец Блоки Id Система
/dev/sdb1 1 121601 976760001 83 Linux
Команда (m для справки): w
Таблица разделов была изменена!
Вызывается ioctl() для перечитывания таблицы разделов.
Синхронизируются диски.
Форматируем новый раздел:
# mkfs.reiserfs /dev/sdb1
Монтируем файловую систему раздела:
# mount /dev/sdb1 /mnt/hd
Проверяем скорость записи данных в файловую систему.
(Для наблюдения за скоростью здесь и в последующих аналогичных случаях на втором терминале вводим watch -n60 killall -SIGUSR1 dd, либо, чтоб не топтать лишний раз клавиши, запишем команду в файл и сделаем его исполняемым.)
# dd if=/dev/zero of=/mnt/hd/000.dd bs=128K count=100000
16140+0 записей считано
16140+0 записей написано
скопировано 2115502080 байт (2,1 GB), 56,9052 c, 37,2 MB/c
32379+0 записей считано
32379+0 записей написано
скопировано 4243980288 байт (4,2 GB), 117,056 c, 36,3 MB/c
46439+0 записей считано
46439+0 записей написано
скопировано 6086852608 байт (6,1 GB), 177,719 c, 34,2 MB/c
65859+0 записей считано
65859+0 записей написано
скопировано 8632270848 байт (8,6 GB), 237,151 c, 36,4 MB/c
75811+0 записей считано
75811+0 записей написано
скопировано 9936699392 байта (9,9 GB), 297,219 c, 33,4 MB/c
90639+0 записей считано
90639+0 записей написано
скопировано 11880235008 байт (12 GB), 357,965 c, 33,2 MB/c
100000+0 записей считано
100000+0 записей написано
скопировано 13107200000 байт (13 GB), 399,318 c, 32,8 MB/c
Оба-на! Скорость записи втрое ниже ожидаемой.
(Между делом замечу, что скорость чтения этого же файла вполне на уровне — около 100 МБ/сек. Баг вылазит только на записи.)
Может ReiserFS «глючная» 🙂 ? Проверим «грязным хаком» 🙂 .
Сначала отмонтируемся:
# umount /dev/sdb1
Потом сотрем содержимое нулевого сектора:
# dd if=/dev/zero of=/dev/sdb count=1
А потом создадим новую файловую систему прямо на жестком диске как на дискете (ключ —f — форсировать выполнение ни о чем не предупреждая):
# mkfs.reiserfs -f /dev/sdb
# mount /dev/sdb /mnt/hd
# dd if=/dev/zero of=/mnt/hd/000.dd bs=128K count=100000
17877+0 записей считано
17877+0 записей написано
скопировано 2343174144 байта (2,3 GB), 27,8018 c, 84,3 MB/c
53827+0 записей считано
53827+0 записей написано
скопировано 7055212544 байта (7,1 GB), 87,8909 c, 80,3 MB/c
89724+0 записей считано
89724+0 записей написано
скопировано 11760304128 байт (12 GB), 148,018 c, 79,5 MB/c
100000+0 записей считано
100000+0 записей написано
скопировано 13107200000 байт (13 GB), 165,614 c, 79,1 MB/c
Совсем другое дело! Видим, что проблема не в файловой системе. Видим также, что винчестеру совершенно не нравится традиционная MS-DOS MBR совместимая разметка с началом раздела на 63-м стандартном 512-байтном секторе, с номером, не кратным размеру нового «хардверного» сектора в 4 КБ (8 «традиционных» секторов по 512 Б). Попробуем обойти это. Отмонтируем файловую, очищаем 0-й сектор для дальнейшей работы:
# umount /dev/sdb
# dd if=/dev/zero of=/dev/sdb count=1
Попробуем создать fdisk’ом раздел с началом на 64-м секторе. Для ввода границ раздела в секторах (LBA), а не в стандартном LCHS применим ключ —u. Акцентирую внимание на том, что fdisk по умолчанию предлагает сектор 63!
# fdisk -u /dev/sdb
Команда (m для справки): n
Действие команды
e расширенный
p основной раздел (1-4)
p
Номер раздела (1-4): 1
Первый сектор (63-1953525167, по умолчанию 63): 64
Последний сектор или +size или +sizeM или +sizeK (64-1953525167, по умолчанию 1953525167):
Используется значение по умолчанию 1953525167
Команда (m для справки): p
Диск /dev/sdb: 1000.2 ГБ, 1000204886016 байт
255 heads, 63 sectors/track, 121601 cylinders, всего 1953525168 секторов
Units = секторы of 1 * 512 = 512 bytes
Disk identifier: 0x5e5c7cb9
Устр-во Загр Начало Конец Блоки Id Система
/dev/sdb1 64 19535251671 976762552 83 Linux
Команда (m для справки): w
Таблица разделов была изменена!
Вызывается ioctl() для перечитывания таблицы разделов.
Синхронизируются диски.
# mkfs.reiserfs /dev/sdb1
# mount /dev/sdb1 /mnt/hd
Проверяем скорость записи на раздел:
# dd if=/dev/zero of=/mnt/hd/000.dd bs=128K count=100000
2889+0 записей считано
2889+0 записей написано
скопировано 378667008 байт (379 MB), 4,32944 c, 87,5 MB/c
42386+0 записей считано
42386+0 записей написано
скопировано 5555617792 байта (5,6 GB), 64,369 c, 86,3 MB/c
87304+0 записей считано
87304+0 записей написано
скопировано 11443109888 байт (11 GB), 124,384 c, 92,0 MB/c
100000+0 записей считано
100000+0 записей написано
скопировано 13107200000 байт (13 GB), 140,365 c, 93,4 MB/c
В целом недурно и значительно ближе к максимально возможной скорости записи.
При организации 2-х и более первичных разделов придерживаемся того же правила: начало каждого раздела должно быть на секторе с номером, кратным как минимум 8-ми. Для этого рассчитываем на калькуляторе кратным 8-ми (минус 1 сектор) номер последнего сектора предыдущего раздела и вводим его fdisk’ом . Требуемый «правильный» номер начального сектора следующего раздела fdisk предложит по умолчанию сам.
В этом примере номер сектора второго раздела я подобрал кратным 64-м:
# fdisk -u /dev/sdb
Команда (m для справки): n
Действие команды
e расширенный
p основной раздел (1-4)
p
Номер раздела (1-4): 1
Первый сектор (63-1953525167, по умолчанию 63): 64
Последний сектор или +size или +sizeM или +sizeK (64-1953525167, по умолчанию 1953525167): 976639999
Команда (m для справки): n
Действие команды
e расширенный
p основной раздел (1-4)
p
Номер раздела (1-4): 2
Первый сектор (976640000-1953525167, по умолчанию 976640000):
Используется значение по умолчанию 976640000
Последний сектор или +size или +sizeM или +sizeK (976640000-1953525167, по умолчанию 1953525167):
Используется значение по умолчанию 1953525167
Команда (m для справки): p
Диск /dev/sdb: 1000.2 ГБ, 1000204886016 байт
255 heads, 63 sectors/track, 121601 cylinders, всего 1953525168 секторов
Units = секторы of 1 * 512 = 512 bytes
Disk identifier: 0x17d66173
Устр-во Загр Начало Конец Блоки Id Система
/dev/sdb1 64 976639999 488319968 83 Linux
/dev/sdb2 976640000 1953525167 488442584 83 Linux
Команда (m для справки): w
Таблица разделов была изменена!
Вызывается ioctl() для перечитывания таблицы разделов.
Синхронизируются диски.
Форматируем, монтируем, проверяем скрость записи:
# mkfs.reiserfs /dev/sdb2
# mount /dev/sdb2 /mnt/hd
# dd if=/dev/zero of=/mnt/hd/000.dd bs=128K count=100000
33765+0 записей считано
33765+0 записей написано
скопировано 4425646080 байт (4,4 GB), 51,3811 c, 86,1 MB/c
72486+0 записей считано
72486+0 записей написано
скопировано 9500884992 байта (9,5 GB), 111,47 c, 85,2 MB/c
100000+0 записей считано
100000+0 записей написано
скопировано 13107200000 байт (13 GB), 153,375 c, 85,5 MB/c
Рассмотрим совсем запущенный случай для логического тома в расширенном разделе.
Т. к. во времена господства MS-DOS расширенный раздел был придуман для программной эмуляции еще одного (второго) жесткого диска на свободном пространстве уже имеющегося накопителя, то для организации первого логического тома в расширенном разделе fdisk предложит нам создать его начальный сектор с номером n+63, где n — начальный сектор расширенного раздела. Нам же необходимо для соблюдения условия кратности 8-ми сектор n+64.
Т. е., сначала нам надо организовать расширенный раздел с номером начального сектора, кратным 8-ми. После чего будем создавать логический том в расширенном разделе также с начальным сектором, кратным восьми.
Отмонтируем и удалим fdisk’ом 2-й основной раздел.
После чего на его месте создадим расширенный со вложенным логическим томом.
# fdisk -u /dev/sdb
Команда (m для справки): p
Диск /dev/sdb: 1000.2 ГБ, 1000204886016 байт
255 heads, 63 sectors/track, 121601 cylinders, всего 1953525168 секторов
Units = секторы of 1 * 512 = 512 bytes
Disk identifier: 0x00054d40
Устр-во Загр Начало Конец Блоки Id Система
/dev/sdb1 64 976639999 488319968 83 Linux
Команда (m для справки): n
Действие команды
e расширенный
p основной раздел (1-4)
e
Первый сектор (976640000-1953525167, по умолчанию 976640000):
Используется значение по умолчанию 976640000
Последний сектор или +size или +sizeM или +sizeK (976640000-1953525167, по умолчанию 1953525167):
Используется значение по умолчанию 1953525167
Команда (m для справки): p
Диск /dev/sdb: 1000.2 ГБ, 1000204886016 байт
255 heads, 63 sectors/track, 121601 cylinders, всего 1953525168 секторов
Units = секторы of 1 * 512 = 512 bytes
Disk identifier: 0x00054d40
Устр-во Загр Начало Конец Блоки Id Система
/dev/sdb1 64 976639999 488319968 83 Linux
/dev/sdb2 976640000 1953525167 488442584 5 Расширенный
Команда (m для справки): n
Действие команды
l логический (5 или более)
p основной раздел (1-4)
l
Первый сектор (976640063-1953525167, по умолчанию 976640063): 976640064
Последний сектор или +size или +sizeM или +sizeK (976640064-1953525167, по умолчанию 1953525167):
Используется значение по умолчанию 1953525167
Команда (m для справки): p
Диск /dev/sdb: 1000.2 ГБ, 1000204886016 байт
255 heads, 63 sectors/track, 121601 cylinders, всего 1953525168 секторов
Units = секторы of 1 * 512 = 512 bytes
Disk identifier: 0x00054d40
Устр-во Загр Начало Конец Блоки Id Система
/dev/sdb1 64 976639999 488319968 83 Linux
/dev/sdb2 976640000 1953525167 488442584 5 Расширенный
/dev/sdb5 976640064 1953525167 488442552 83 Linux
Команда (m для справки): w
Таблица разделов была изменена!
Вызывается ioctl() для перечитывания таблицы разделов.
Синхронизируются диски.
# mkfs.reiserfs /dev/sdb5
# mount /dev/sdb5 /mnt/hd
# dd if=/dev/zero of=/mnt/hd/000.dd bs=128K count=100000
6585+0 записей считано
6585+0 записей написано
скопировано 863109120 байт (863 MB), 11,2747 c, 76,6 MB/c
37947+0 записей считано
37947+0 записей написано
скопировано 4973789184 байта (5,0 GB), 72,3125 c, 68,8 MB/c
68410+0 записей считано
68410+0 записей написано
скопировано 8966635520 байт (9,0 GB), 131,587 c, 68,1 MB/c
99030+0 записей считано
99030+0 записей написано
скопировано 12980060160 байт (13 GB), 191,798 c, 67,7 MB/c
100000+0 записей считано
100000+0 записей написано
скопировано 13107200000 байт (13 GB), 193,386 c, 67,8 MB/c
Working very good! Что и требовалось доказать.
Отмонтируем раздел для дальнейших экспериментов:
# umount /dev/sdb5
В свою очередь WD предлагает нам свой вариант согласования старой разметки с новым низкоуровневым форматом путем установки перемычки на контакты 7-8. В этом случае винчестер сдвигает трансляцию на 1 сектор (512 Б), «подсовывая» под начало раздела свой «родной» 64-й сектор, вместо 63-го. Для пущей понятности наглядно продемонстируем, что в этом случае происходит.
Очистим первые 500 секторов для дальнейшей работы:
# dd if=/dev/zero of=/dev/sdb count=500
Создадим новый раздел классическим методом и отформатируем:
# fdisk /dev/sdb
# mkfs.reiserfs /dev/sdb1
Посмотрим содержимое сектора 0:
# hdparm —read-sector 0 /dev/sdb
/dev/sdb:
reading sector 0: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 8ba4 c746 0000 0100
0001 fe 83 ffff 003f 0000 5982 7470 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 aa55
Визуально напоминает 🙂 живую таблицу разделов (сигнатура aa55) с одним разделом Линукс (тип 83).
Почитаем сектор 191 — в нем живет рейзерэфэсный суперблок:
# hdparm —read-sector 191 /dev/sdb
/dev/sdb:
reading sector 191: succeeded
0b30 0e8e ce00 0e8d 2013 0000 0012 0000
0000 0000 2000 0000 0400 0000 0f87 3caf
0384 0000 001e 0000 0000 0000 1000 03cc
0002 0001 6552 7349 7245 4632 0073 0000
0003 0000 0002 1d1d 0002 0000 0000 0000
0001 0000 d748 2bfc fd2a bd4f 9d95 4612
4d4c 605d 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0001 0000
0003 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
Прошу поверить на слово — это именно он 🙂 .
Выключаем тазик:
Cтавим перемычку на контакты 7-8. Включаемся.
Диск /dev/sda: 1000.2 ГБ, 1000204886016 байт
255 heads, 63 sectors/track, 121601 cylinders
Units = цилиндры of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000945ef
Устр-во Загр Начало Конец Блоки Id Система
/dev/sdb1 1 127 1020096 b W95 FAT32
/dev/sdb2 128 5099 39937590 83 Linux
/dev/sdb3 * 5100 10071 39937590 7 HPFS/NTFS
/dev/sdb4 10072 121601 895864725 7 HPFS/NTFS
Диск /dev/sdb: 1000.2 ГБ, 1000204886016 байт
255 heads, 63 sectors/track, 121601 cylinders
Units = цилиндры of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
На диске /dev/sdb отсутствует верная таблица разделов
Раздел как ветром сдуло. Куда ж он делся? «Пошукаем псису»:
# hdparm —read-sector 0 /dev/sdb
/dev/sdb:
reading sector 0: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
# hdparm —read-sector 191 /dev/sdb
/dev/sdb:
reading sector 191: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
Пусто. Поищем суперблок в окрестностях:
# hdparm —read-sector 190 /dev/sdb
reading sector 190: succeeded
0b30 0e8e ce00 0e8d 2013 0000 0012 0000
0000 0000 2000 0000 0400 0000 0f87 3caf
0384 0000 001e 0000 0000 0000 1000 03cc
0002 0001 6552 7349 7245 4632 0073 0000
0003 0000 0002 1d1d 0002 0000 0000 0000
0001 0000 d748 2bfc fd2a bd4f 9d95 4612
4d4c 605d 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0001 0000
0003 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
Вот он! Оказался на 190-м секторе. Соответственно, таблица разделов сейчас находится на секторе -1 (минус 1), т. е. не в пользовательской зоне и она недоступна штатными средствами.
Если сейчас в таком виде, с установленной перемычкой 7-8, создать классическую разметку и отформатировать новоиспеченный раздел, то таблица разделов окажется на «заводском» 1-м секторе. Но начало раздела — на «удобном» винчестеру «заводском» 64-м, суперблок — на 192-м. Т. е. логика раздела и ФС будет кратна «хардверному» сектору в 4 КБ и ничего тормозить не будет. Разумеется, перемычку после этих операций снимать будет нельзя!
Это есть весьма оригинальное «хардверное» решение проблемы от WD, и для создания единственного основного раздела вполне успешно заменяет «пляски с бубном» в fdisk. К сожалению, трюк с перемычкой работает только для одного основного раздела на весь объем устройства, либо же только для первого основного раздела. Если всё делать «по умолчанию», то для следующих после первого основных разделов, либо логических томов в расширенном разделе, кратность будет опять переломана, и работа в рамках всех разделов, кроме первого, будет идти с тормозами, и никакие перемычки здесь уже не помогут.
В целом мы убедились, что проявленная багофича связана с тяжелым наследием разметки дисков по умолчанию, совместимым с классическим MS-DOS MBR.
При создании же посекторных копий других дисков на исследуемый диск тем же dd, либо отказоустойчивыми ddrescue и dd_rescue, без учёта имеющихся логических структур, в связи со вполне приемлемой эмуляцией 512-байтного сектора, никаких критических сбоев в работе замечено не было. Вкупе с демократичной ценой, винчестер демонстрирует приличные скоростные характеристики при последовательных записи и чтении и низкую рабочую температуру, характерную для всех накопителей WD Green. И после внимательного ознакомления с написанным материалом может однозначно быть рекомендован к эксплуатации в Линукс.
Виталий Розизнаный AKA Rozik, специально для rlab.ru.
Перепечатка или цитирование разрешены при условии сохранения ссылок на первоисточник: R.LAB, восстановление жестких дисков, восстановление информации.
Бук к разряду проблемных не относится.
С винтом тоже всё ОК.
Более ничего сказать не могу.
На будущее, чтоб не постить простыни достаточно [b]smartctl -iA[/b]
Еще smart. Этого достаточно?
# smartctl —xall /dev/sda
smartctl 5.40 2010-07-12 r3124 [i686-pc-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Scorpio Blue Serial ATA family
Device Model: WDC WD3200BEVT-22ZCT0
Serial Number: WD-WXE608LE7753
Firmware Version: 11.01A11
User Capacity: 320 072 933 376 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Mon Feb 20 13:30:33 2012 MSK
SMART support is: Available — device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (10800) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 127) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x303f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always — 0
3 Spin_Up_Time 0x0027 186 185 021 Pre-fail Always — 1658
4 Start_Stop_Count 0x0032 098 098 000 Old_age Always — 2063
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always — 0
7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always — 0
9 Power_On_Hours 0x0032 086 086 000 Old_age Always — 10637
10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always — 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always — 0
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always — 1905
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always — 164
193 Load_Cycle_Count 0x0032 127 127 000 Old_age Always — 221955
194 Temperature_Celsius 0x0022 102 081 000 Old_age Always — 45
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always — 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always — 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline — 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always — 0
200 Multi_Zone_Error_Rate 0x0009 100 253 051 Pre-fail Offline — 0
General Purpose Logging (GPL) feature set supported
General Purpose Log Directory Version 1
SMART Log Directory Version 1 [multi-sector log support]
GP/S Log at address 0x00 has 1 sectors [Log Directory]
SMART Log at address 0x01 has 1 sectors [Summary SMART error log]
SMART Log at address 0x02 has 5 sectors [Comprehensive SMART error log]
GP Log at address 0x03 has 6 sectors [Ext. Comprehensive SMART error log]
SMART Log at address 0x06 has 1 sectors [SMART self-test log]
GP Log at address 0x07 has 1 sectors [Extended self-test log]
SMART Log at address 0x09 has 1 sectors [Selective self-test log]
GP Log at address 0x10 has 1 sectors [NCQ Command Error]
GP Log at address 0x11 has 1 sectors [SATA Phy Event Counters]
GP/S Log at address 0x80 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x81 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x82 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x83 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x84 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x85 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x86 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x87 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x88 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x89 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x8a has 16 sectors [Host vendor specific log]
GP/S Log at address 0x8b has 16 sectors [Host vendor specific log]
GP/S Log at address 0x8c has 16 sectors [Host vendor specific log]
GP/S Log at address 0x8d has 16 sectors [Host vendor specific log]
GP/S Log at address 0x8e has 16 sectors [Host vendor specific log]
GP/S Log at address 0x8f has 16 sectors [Host vendor specific log]
GP/S Log at address 0x90 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x91 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x92 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x93 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x94 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x95 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x96 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x97 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x98 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x99 has 16 sectors [Host vendor specific log]
GP/S Log at address 0x9a has 16 sectors [Host vendor specific log]
GP/S Log at address 0x9b has 16 sectors [Host vendor specific log]
GP/S Log at address 0x9c has 16 sectors [Host vendor specific log]
GP/S Log at address 0x9d has 16 sectors [Host vendor specific log]
GP/S Log at address 0x9e has 16 sectors [Host vendor specific log]
GP/S Log at address 0x9f has 16 sectors [Host vendor specific log]
GP/S Log at address 0xa0 has 16 sectors [Device vendor specific log]
GP/S Log at address 0xa1 has 16 sectors [Device vendor specific log]
GP/S Log at address 0xa2 has 16 sectors [Device vendor specific log]
GP/S Log at address 0xa3 has 16 sectors [Device vendor specific log]
GP/S Log at address 0xa4 has 16 sectors [Device vendor specific log]
GP/S Log at address 0xa5 has 16 sectors [Device vendor specific log]
GP/S Log at address 0xa6 has 16 sectors [Device vendor specific log]
GP/S Log at address 0xa7 has 16 sectors [Device vendor specific log]
GP/S Log at address 0xa8 has 1 sectors [Device vendor specific log]
GP/S Log at address 0xa9 has 1 sectors [Device vendor specific log]
GP/S Log at address 0xaa has 1 sectors [Device vendor specific log]
GP/S Log at address 0xab has 1 sectors [Device vendor specific log]
GP/S Log at address 0xac has 1 sectors [Device vendor specific log]
GP/S Log at address 0xad has 1 sectors [Device vendor specific log]
GP/S Log at address 0xae has 1 sectors [Device vendor specific log]
GP/S Log at address 0xaf has 1 sectors [Device vendor specific log]
GP/S Log at address 0xb0 has 1 sectors [Device vendor specific log]
GP/S Log at address 0xb1 has 1 sectors [Device vendor specific log]
GP/S Log at address 0xb2 has 1 sectors [Device vendor specific log]
GP/S Log at address 0xb3 has 1 sectors [Device vendor specific log]
GP/S Log at address 0xb4 has 1 sectors [Device vendor specific log]
GP/S Log at address 0xb5 has 1 sectors [Device vendor specific log]
GP/S Log at address 0xb6 has 1 sectors [Device vendor specific log]
GP/S Log at address 0xb7 has 1 sectors [Device vendor specific log]
GP/S Log at address 0xc0 has 1 sectors [Device vendor specific log]
GP Log at address 0xc1 has 24 sectors [Device vendor specific log]
GP/S Log at address 0xe0 has 1 sectors [SCT Command/Status]
GP/S Log at address 0xe1 has 1 sectors [SCT Data Transfer]
SMART Extended Comprehensive Error Log Version: 1 (6 sectors)
No Errors Logged
SMART Extended Self-test Log Version: 1 (1 sectors)
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
SCT Status Version: 2
SCT Version (vendor specific): 258 (0x0102)
SCT Support Level: 1
Device State: Active (0)
Current Temperature: 45 Celsius
Power Cycle Min/Max Temperature: 22/45 Celsius
Lifetime Min/Max Temperature: 25/66 Celsius
Under/Over Temperature Limit Count: 0/0
SCT Temperature History Version: 2
Temperature Sampling Period: 1 minute
Temperature Logging Interval: 1 minute
Min/Max recommended Temperature: 0/60 Celsius
Min/Max Temperature Limit: 1/85 Celsius
Temperature History Size (Index): 128 (47)
SCT Error Recovery Control:
Read: Disabled
Write: Disabled
SATA Phy Event Counters (GP Log 0x11)
ID Size Value Description
0x0001 2 0 Command failed due to ICRC error
0x0002 2 0 R_ERR response for data FIS
0x0003 2 0 R_ERR response for device-to-host data FIS
0x0004 2 0 R_ERR response for host-to-device data FIS
0x0005 2 0 R_ERR response for non-data FIS
0x0006 2 0 R_ERR response for device-to-host non-data FIS
0x0007 2 0 R_ERR response for host-to-device non-data FIS
0x000a 2 2 Device-to-host register FISes sent due to a COMRESET
0x8000 4 3523 Vendor specific
acer extenza 5630
Диск ata WDC WD3200BEVT-22ZCT0
Smart——
# smartctl —all /dev/sda
smartctl 5.40 2010-07-12 r3124 [i686-pc-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Scorpio Blue Serial ATA family
Device Model: WDC WD3200BEVT-22ZCT0
Serial Number: WD-WXE608LE7753
Firmware Version: 11.01A11
User Capacity: 320 072 933 376 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Mon Feb 20 13:25:46 2012 MSK
SMART support is: Available — device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (10800) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 127) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x303f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always — 0
3 Spin_Up_Time 0x0027 186 185 021 Pre-fail Always — 1658
4 Start_Stop_Count 0x0032 098 098 000 Old_age Always — 2063
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always — 0
7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always — 0
9 Power_On_Hours 0x0032 086 086 000 Old_age Always — 10637
10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always — 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always — 0
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always — 1905
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always — 164
193 Load_Cycle_Count 0x0032 127 127 000 Old_age Always — 221948
194 Temperature_Celsius 0x0022 102 081 000 Old_age Always — 45
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always — 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always — 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline — 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always — 0
200 Multi_Zone_Error_Rate 0x0009 100 253 051 Pre-fail Offline — 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
1. Полностью модель ноута.
2. Полностью модель диска и СМАРТ атрибуты в студию.
Я имел в виду следующее:
Вот эта команда
dd if=/dev/zero of=/mnt/hd/000.dd bs=128K count=100000
У вас дает результат 80Мб/с, а у меня 40. И я хотел бы просто выяснить причину. Причем, не совсем для праздного интереса — ноут подтормаживает и иногда ни слабо.
Что "возможно"? У вас не AF диск. Пляска с выравниванием ему не требутся.
На Юниксфоруме вам уже сказали, что вы лечите то, что не болит.
Копирование в пределах одного физустройства никогда не будет равно по скорости копированию с одного физ. устройства на другое. Что у вас, собственно, и наблюдается.
Возможно. Это означает, что 30-40Мб/с — это нормально и больше не получить?
WD3200BEVT — это не Advanced Format диск.
Если вы только знакомитесь с восстановлением данных, начните с прочтения этой статьи для понимания принципов. Как это работает, почему вообще возможно восстановление после удаления или форматирования.
Освойте самостоятельное восстановление данных с исправных накопителей с помощью данной программы.
Изучение устройства и принципа работы носителей информации можно начать с этих статей.
Познакомьтесь с этой бесплатной утилитой, она поможет как в изучении аппаратных особенностей накопителей, так и при выполнении диагностики их состояния.
Видео ролики дополняют тематические статьи нашего сайта.
Задавайте вопросы. Вам ответит специалист, работающий с интересующим вас типом устройств.
Диски, контроллеры, ОС и Advanced Format
Казалось бы, что про диски Advanced Format за последние 4 года успели узнать все. Публикаций действительно много, но настало время рассмотреть все технические подробности и подводные камни в одной большой статье. Речь пойдёт об использовании AF-дисков в серверах, и я заметил, что для большинства администраторов даже в крупных компаниях знание предмета в большинстве случаев сводится к «это как-то связано с современными дисками, но у меня всё работает».
Что такое Advanced Format
Advanced Format — новый формат разметки секторов, используемый в некоторых жёстких дисках. Вместо традиционного сектора размером 512 байт используется 4096 байт. Некоторые диски SCSI/SAS/FC могут использовать 520- и 528-байтные «толстые» сектора для дополнительного контроля целостности данных, но это не относится к теме данной статьи.
Увеличение размера сектора в 8 раз связано с необходимостью повышения эффективности размещения данных на современных дисках. Накладные расходы, связанные с 512-байтной разметкой, начинают мешать дальнейшему увеличению ёмкости HDD. Помимо служебных полей в каждом 512-байтном секторе присутствует поле с кодом коррекции ошибок (ECC) длиной в 50 байт. В 4096-байтном секторе длина ECC-поля составляет 100 байт. Общее эффективность хранения данных удалось улучшить примерно на 10%.
Естественно, поддержка нестандартных секторов требуется со стороны дисковых контроллеров и операционных систем. Для решения проблем с совместимостью был ввёден дополнительный стандарт 512E, который обозначает диски с физическим размером сектора 4096 байт, но при этом эмулирующие обычный размер сектора в 512 байт. Advanced Format диски без эмуляции обозначаются 4KN. Таким образом, сейчас существует три варианта разметки:
| Формат | Логический размер сектора | Физический размер сектора |
| 512 байт | 512 байт | |
| 512 байт | 4096 байт (4КиБ) | |
| 4096 байт (4КиБ) | 4096 байт (4КиБ) |
Совместимость
Операционные системы
На первый взгляд кажется, что использование эмуляции 512-байтного сектора снимает все проблемы с совместимостью, но это не так. Во-первых, сразу же возникает проблема с производительностью. Что произойдет при записи блока размером 512 байт на диск с размером сектора 4096 байт (пусть и эмулирующий наличие секторов 512 байт)? Произойдёт классический процесс read-modify-write, вместо одной операции понадобится две: прочитать сектор 4096 байт, поменять в нём 512 байт (записываемый блок) и записать 4096 байт обратно. Аналогичная проблема проявляется и при отсутствии выравнивания, когда записываемый блок данных может быть достаточно большим и даже кратным 4096 байт, но при этом сдвинут относительно границ реальных секторов:
В современных условиях операции записи блоками меньше 4096 байт встречаются крайне редко, а вот проблема с выравниванием остаётся. Например, в старых Windows (до Windows Server 2008) при установке загрузочный раздел создаётся со смещением в 63 сектора. Так уж исторически сложилось с тех времён, когда BIOS использовал реальную геометрию диска вместо LBA. Разумеется, смещение в 63×512 не делится на 4096, что приводит к нарушению выравнивания для всех последующих разделов и снижению производительности. Впервые на данную проблему обратили внимание в связи с использованием RAID-контроллеров и необходимостью выравнивания разделов по границам страйпа и она была решена в Windows Vista/ Windows Server 2008 (и примерно в то же время — в других ОС) введением выравнивания по границам в 1024КиБ (1МиБ), т.е. первый раздел создается со смещением в 2048 512-байтных секторов.
Почему именно 1МиБ, если подойдёт меньшее смещение (главное — чтобы делилось на 4096 байт)? Просто потому, что нужен запас, ведь помимо физического диска в качестве блочного устройства могут выступать тома на RAID-контроллерах (с размером страйпа по умолчанию, например, у Adaptec в 256КиБ), SSD (с большим размером страниц) или образы дисков при использовании виртуализации, рекомендуемый размер NTFS-кластера для SQL или Exchange равен 64КиБ и т.д.
Проблема номер два — возможная потеря данных для сценариев с синхронной записью. Для ситуаций с записью блока меньше 4096 байт или невыравненного блока синхронной записи по факту не получится. Остаётся «научить» ОС не использовать при записи блоки меньше 4096 байт на диски 512E, но с этим есть определённые проблемы.
Microsoft
- Windows 8, 8.1
- Windows Server 2012, 2012 R2
- Windows 7 w/ MS KB 982018
- Windows 7 SP1
- Windows Server 2008 R2 w/ MS KB 982018
- Windows Server 2008 R2 SP1
- Windows Vista w/ MS KB 2553708
- Windows Server 2008 w/ MS KB 2553708
- Windows 8, 8.1
- Windows Server 2012, 2012 R2
Проверить выравнивание существующих разделов и задать смещение для новых разделов в Windows можно при помощи diskpart. Пример (раздел на диске 0 со смещением в 1024КиБ или 2048 512-байтных секторов):
Проверить проще всего через WMI (пример):
В колонке StartingOffset должно быть 1024КиБ для первого раздела, для остальных — должно делиться на 1024КиБ, это означает, что и на 4096 байт и все другие «хорошие числа» (размеры страйпов и NTFS-кластеров) всё будет делиться.
Напомню, что в современных Windows смещение в 1024КиБ и так используется по умолчанию, так что проверять/выставлять его вручную нужно лишь для ОС из «63-секторной» эпохи. При автоматическом создании GPT-разметки (через Disk Management) на 512N или 512E диске вы увидите смещение для первого раздела в 17КиБ. Это не повод для тревоги, так как это служебный раздел MSR. Первый стандартный раздел будет создан со смещением в 135266304 байт (129МиБ) — прекрасно делится на любое из наших «хороших чисел».
Linux
- RHEL 6.1
- SLES 11 SP2
- Ubuntu 13.10
- Ubuntu 12.04.4
- RHEL 6.1
- SLES 11 SP2
- Ubuntu 13.10
- Ubuntu 12.04.4
Посмотреть размеры физического и логического блоков можно в /sys/block/sdX/queue/physical_block_size и в /sys/block/sdX/queue/logical_block_size соответственно.
GNU Fdisk будет автоматически использовать смещение в 1МиБ при запуске с ключами -c и -u (отключить режим совместимости с DOS и использовать сектор в качестве единицы измерения). Обычный Fdisk не умеет работать с GPT, так что он бесполезен для дисков >2ТиБ, и нужно использовать Parted или GPT Fdisk. Последний по умолчанию использует для 512N/512E дисков нужное нам смещение в 2048 секторов:
Пример для GNU Parted (для 512N/512E дисков):
В LVM всё хорошо: смещение по умолчанию равно 1МиБ и размер PE (physical extent) кратен 1МиБ.
VMware
Статья в базе знаний VMware утверждает, что ни 512E, ни 4KN диски не поддерживаются. Поддержка дисков 4KN заявлена в vSphere 6.0.
С появлением VMFS-5 мы получили единый размер блока — 1МиБ и правильное 1МиБ-смещение для первого раздела. Раньше использовалось не всегда подходящее смещение в 64КиБ. Но всё это не отменяет заявления VMware о том, что 512E диски не поддерживаются. Видимо, это связано с тем, что формат VMDK хранит данные с гранулярностью 512 байт.
Прочие ОС
Mac OSX поддерживает Advanced Format начиная с Tiger. Остаются ещё FreeBSD и прочие *BSD, Oracle Solaris и множество других ОС, но детальное рассмотрение ситуации с Advanced Format дисками в них выходит за рамки данной статьи.
Сервисы Microsoft
Hyper-V
Exchange Server
- Все диски, используемые в группе обеспечения доступности (Database Availability Group, DAG) Exchange для хранения баз и логов, должны использовать одинаковый физический размер сектора.
- Диски 4KN не поддерживаются
- Диски 512E поддерживаются начиная с Exchange 2010 Service Pack 2
SQL Server
Ситуация та же, что и для Exchange Server — в отказоустойчивых конфигурациях для баз и логов на всех узлах должы использоваться диски с одинаковым физическим размером сектора.
При использовании Storage Spaces возникает интересная ситуация: презентуемый размер физического сектора оказывается равным 4КиБ вне зависимости от того, из каких дисков собран Storage Spaces (том Storage Spaces можно создать из разных дисков — 512N и 512E, смешивать с 4KN, естественно, нельзя, кроме случаев использования tiering’а с SSD). Формат VHDX (виртуальный диск) по умолчанию создаётся как 512E. В этом можно убедиться, запустив fsutil fsinfo ntfsinfo <имя диска>:
При использовании VHDX на томе Storage Spaces (или аппаратном RAID), состоящем из 4KN дисков, сам VHDX тоже желательно сделать 4KN:
Безопасно ли это для SQL и других приложений, использующих синхронную запись? Ответ — да, так как большая гранулярность хранения не нарушает целостности данных, на производительность это тоже не влияет, так как 4096 делится на 512.
Сервисы, использующие ESENT
Не совсем актуальная проблема в Windows Server 2008. Сервисы, использующие в работе Extensible Storage Engine API (AD, WINS, DHCP) могут упасть при изменении размера физического сектора (например, при миграции с 512N-диска на 512E). Подробное описание и хотфикс смотрите тут.
Прочее ПО
-
. поддерживает диски Advanced Format (512E и 4KN) начиная с версии 2012 revision 1798 Service Pack 2. Более ранние выпуски могут работать с дисками 512E, но Symantec утверждает, что подобное сочетание не поддерживается официально. не поддерживает диски 4KN.
Контроллеры
- Диски 4KN и 512N/512E смешивать в одном массиве нельзя.
- У контроллеров Adaptec и LSI метаданные размещаются в конце диска, пользовательское пространство доступно с LBA0. Это означает, что проблем с выравниванием для 512E дисков не будет.
- Массив из 4KN дисков так же будет иметь физический/логический размер сектора 4КиБ, т.е. для загрузки с них нужны GPT и UEFI.
- Не забывайте вместе с прошивкой обновлять утилиты управления и драйверы.
- Как будет презентоваться LUN, созданный на 512E дисках — 512N или 512E? Из того, что удалось проверить: контроллеры LSI 9260, Adaptec 6-й серии, СХД Infortrend ESDS сообщают 512N (логический/физический блоки 512 байт), т.е. проблема с синхронной записью остаётся. Обязательно используйте write-back кэш (естественно, с защитой) и UPS. Причём не исключено, что при смене прошивки СХД и контроллер могут внезапно повести себя «правильно», и LUN’ы превратятся в 512E со всеми вытекающими последствиями для совместимости.
Adaptec by PMC
- SAS HBA серий 5 и 6: поддерживают 512E, не поддерживают 4KN
- SAS HBA серий 6H и 7H: поддерживают 512E, 4KN — начиная с прошивки 10467.
- RAID контроллеры серий 7 и 8: поддерживают 512E, 4KN — начиная с прошивки 30862.
LSI/Avago
- Старые контроллеры на базе LSI1078: не поддерживают диски Advanced Format совсем
LSI 3ware серии 9750 на базе LSI2108 и более ранние 3ware: не поддерживают диски Advanced Format совсем.- LSISAS2108 (LSI 9260/61/80): поддерживают 512E начиная с прошивки MR4.8, 4KN не поддерживают. Список совместимости (4KN диски присутствуют, но, видимо, относятся к LSI 2208, см. ниже).
- LSISAS2208 (LSI 9265/66/71/85/86): поддерживают 512E начиная с прошивки MR5.5, поддерживают 4KN начиная с прошивки MR5.8. Список совместимости.
- LSISAS3108 (LSI 9361/80): поддерживают 512E и 4KN. Список совместимости.
- SAS HBA на базе LSISAS2008 и LSISAS2308 (LSI 9211/9200/9207): поддерживают 512E и 4KN. Список совместимости.
- SAS HBA на базе LSISAS3008 (LSI 9311/9300): поддерживают 512E и 4KN. Список совместимости.
- RAID на базе LSISAS2008 (LSI 9240, прошивка iMR): поддерживают 512E, 4KN не поддерживают. Список совместимости.
- RAID на базе LSISAS3008 (LSI 9340, прошивка iMR): поддерживают 512E, 4KN не поддерживают. Список совместимости.
Это свойство как раз и отвечает за презентуемые хосту размеры блоков:
Default (0): при наличии в томе дисков 512E он презентуется как 512E. Если все диски — 512N, тогда том презентуется как 512N
Disabled (1): Том всегда презентуется как 512N несмотря на наличие дисков 512E
Forced (2): Том всегда презентуется как 512E даже при отсутствии дисков 512E
Emulation Type был портирован и на SAS2 контроллеры (LSI 2108/2208), но без значения Forced (2).
Программный RAID в чипсетах Intel (RST/RSTe)
4KN не поддерживается совсем, Intel RST на дисках 512E требует свежих драйверов.
Advanced Format в дисках корпоративного класса. Что нас ждёт?
Речь пойдёт о дисках корпоративного класса последний серий. Десктопные HDD и позиционируемые для NAS или видеонаблюдения сюда не попали.
| Вендор | Серия | Форм-фактор | Интерфейсы | Скорость вращения шпинделя, об/мин | Дополнительно | |||
| Seagate | Enterprise Performance 10K HDD (10k.8) | 2.5″ | SAS | 10000 | Y | Y | Y | для 512N ёмкость ограничена: 600/1200ГБ |
| Seagate | Enterprise Performance 15K HDD (15k.5) | 2.5″ | SAS | 15000 | Y | Y | Y | 32ГБ встроенного SSD-кэша |
| Seagate | Enterprise Capacity 2.5 HDD (V.3) | 2.5″ | SAS, SATA | 7200 | Y | Y | ||
| Seagate | Enterprise Capacity 3.5 HDD (V.4) | 3.5″ | SAS, SATA | 7200 | Y | Y | ||
| Seagate | Archive HDD | 3.5″ | SATA | 7200 | Y | Позиционируются для архивного применения, меньше MTBF и хуже BER | ||
| Seagate | Terascale HDD | 3.5″ | SATA | 5900/7200 | Y | Позиционируются для облачного применения, меньше MTBF и хуже BER | ||
| HGST | Ultrastar C10K1800 | 2.5″ | SAS | 10000 | Y | Y | Y | для 512N ёмкость ограничена: 300/600/900/1200ГБ |
| HGST | Ultrastar C15K600 | 2.5″ | SAS | 15000 | Y | Y | Y | |
| HGST | Ultrastar C7K1000 | 2.5″ | SAS | 7200 | Y | |||
| HGST | Ultrastar He 8 | 3.5″ | SAS, SATA | 7200 | Y | Y | ||
| HGST | Ultrastar He 6 | 3.5″ | SAS, SATA | 7200 | Y | |||
| HGST | Ultrastar 7K6000 | 3.5″ | SAS, SATA | 7200 | Y | Y | ||
| HGST | MegaScale DC 4000.B | 3.5″ | SATA | 5400 | Y | Позиционируются для облачного применения, меньше MTBF и хуже BER | ||
| WD | Xe | 2.5″/3.5″ | SAS | 10000 | Y | |||
| WD | Re | 3.5″ | SATA | 7200 | Y | |||
| WD | Se | 3.5″ | SATA | 7200 | Y | Позиционируются для облачного применения, меньше MTBF и хуже BER | ||
| WD | Ae | 3.5″ | SATA | 5760 | Y | ? | Позиционируются для архивного применения, меньше MTBF и хуже BER | |
| Toshiba | AL13SE | 2.5″ | SAS | 10000 | Y | |||
| Toshiba | AL13SX | 2.5″ | SAS | 15000 | Y | |||
| Toshiba | AL13SEL | 3.5″ | SAS | 10000 | Y | |||
| Toshiba | MG03ACA/MG03SCA | 3.5″ | SAS, SATA | 7200 | Y | |||
| Toshiba | MG04ACA | 3.5″ | SATA | 7200 | Y | Y | ||
| Toshiba | MG04SCA | 3.5″ | SAS | 7200 | Y | Y | ||
| Toshiba | MC04ACA | 3.5″ | SATA | 7200 | Y | Позиционируются для облачного применения, меньше MTBF и хуже BER |
Тенденцию вы видите сами — Advanced Format окончательно проник из десктопного сегмента в корпоративный. Быстрые SAS диски 10/15 тыс. об/мин ещё выпускаются в варианте 512N, но наращивание плотности заставляет производителей использовать 4КиБ-сектора: Seagate 10k.8 и HGST Ultrastar C10K1800 ёмкостью 1800ГБ доступны только в вариантах 512E и 4KN. Все диски объёмом больше 5ТБ за исключением HGST Ultrastar He 6 — только Advanced Format.
SSD имеют свои особенности. Читать и записывать данные можно страницами, размер которых составляет 2–4–8–16КиБ в зависимости от архитектуры SSD. При этом для записи нужно обеспечить предварительное стирание ячеек, которое осуществляется не постранично, а блоками по несколько сотен страниц. Например, Samsung 840 EVO имеет блоки по 2МиБ, каждый из которых состоит из 256-ти страниц по 8КиБ. При этом, естественно, любой презентуемый хосту размер блока — 512 или 4096 байт — будет абстракцией.
Некоторые из современных SAS/SATA SSD эмулируют 512E-диск, но большая часть из соображений совместимости — 512N. Каких-либо особых мер в связи с этим предпринимать не требуется, так как в SSD корпоративного класса содержимое кэша обязательно защищается от потери питания. Достаточно обеспечить выравнивание по размеру страницы.
Некоторые PCI-E SSD, например, производства Fusion IO дают возможность при помощи фирменных утилит изменить при форматировании размер логического сектора, т.е. переключаться между 512E и 4KN режимами. Для некоторых SSD с интерфейсом SAS это тоже возможно, например, Seagate 1200 поддерживает изменение размера сектора обычным sg_format. Переход на 4КиБ сектор в некоторых сценариях может существенно поднять производительность.
Advanced Format, 512e
Advanced Format — формат разметки области хранения данных на жестких дисках нового поколения, выполненных по технологии 4K (использование физических секторов размером 4 килобайт вместо традиционных 512 байт), разработанный IDEMA Long Data Sector Committee. Технология впервые была применена в жёстких дисках Western Digital.
В настоящее время эта технология внедрена или внедряется всеми производителями жёстких дисков.
За счёт ликвидации лишних межсекторных промежутков удается выиграть примерно 7—11% полезного дискового пространства (по данным производителя). Также улучшается сохранность данных благодаря более эффективной системе исправления ошибок.
Однако длительное время размер сектора в 512 байт был стандартом де-факто, поэтому для работы с существующим программным обеспечением диски с технологией Advanced Format вынуждены эмулировать секторы такого размера, размещая в одном физическом секторе восемь логических.
Операционные системы Windows 7 и Windows Vista не требуют каких-либо мер для достижения оптимального быстродействия, уже поддерживая технологию Advanced Format, а для более старых ОС (в первую очередь — Windows XP) для выравнивания расположения логических секторов относительно физических необходимо воспользоваться программой WD Align, либо ее аналогами, для подготовки диска к работе под ОС Windows XP или перед клонированием диска, содержащего разделы с этой ОС. Также оптимизация возможна запуском этой программы уже после установки ОС.
Основным недостатком этой технологии является падение скорости работы с мелкими (менее 4096 байт) файлами по понятным причинам, однако если не произвести выравнивания разделов при установке или клонировании ОС, не имеющей встроенной поддержки 4K Cluster(другое название технологии Advaced Format), то могут наблюдаться более серьезные проблемы вплоть до трёхкратного падения скорости записи.
Получить дополнительные сведения о технологии WD Align и скачать программу WD Align можно на www.wdc.com
В настоящее время аналогичные технологии с 4Кб сектором стали применять в некоторых своих HDD фирмы Samsung и Seagate.
