netch80 (netch80) wrote,
netch80
netch80

диски с 4K блоками

Те, кто читают жёлтую прессу, знают, что на нас неумолимо надвигаются диски с 4K секторами на поверхности (вместо родных и привычных 512 байт). WD уже начала выпускать такое (пока только в зелёной серии), остальные наблюдают и готовятся к худшему. См. ссылки в конце. Данное событие показало мне всю глубину моей наивности - я думал, что на дисках уже давно секторы килобайт по 32, если не больше.

На днях коллега купил такого зверя, и мы стали его исследовать. В основном интересовало, что сделать, чтобы не нарваться на постоянное пересечение границ и соответствующее снижение производительности. Здесь оказался более-менее внятный метод:

1. Похерить старые привычки. Совместимость с MS-DOS и ближайшими наследниками, когда раздел начинается с 63-го сектора (ибо LBA-assist трансляция в N*255*63) и соответственно не на границе физического блока - должна быть полностью и окончательно выброшена на помойку. В крайнем случае - руками назначить другую геометрию (как минимум N*255*56, а ещё лучше N*128*32).
2. Принять, что отныне минимальная допустимая граница - размер 4KB. А ещё лучше - 1MB, ибо место на диске в таких единицах всё равно уже не считается, а пользы вагон (например, можно stripe size созданного RAID'а поднять до мегабайта). Для сравнения, при N*255*63 выравнивание идёт на ~8MB - что менее экономично:)
3. На создаваемых FS установить размер блока кратным 4KB. Возможно, даже размер фрагмента (имеет прямой смысл для UFS).

bonnie++ показывает потерю в ~20% на последовательном невыровненном чтении и раза в 3 - при работе с FS.

Более грустным и неконструктивным является вывод о возможности собственно обнаружения подобных особенностей у существующих дисков (например, чтобы в режиме прямого дискового ввода/вывода без кэша ОС дать максимум производительности). WD10-EARS и WD15-EARS доступных групп не дают об этом никаких данных через стандартные методы (поля ответа на IDENTIFY DEVICE). Должно быть так:


C возвращаемом из диска по команде IDENTIFY DEVICE (Linux: HDIO_GET_IDENTITY, FreeBSD: IOCATAGPARM) - массиве из 256 16-битных слов в little endian - за эти параметры отвечают следующие слова:

* слово 106 - b15==0, b14==1, b13 - признак "несколько логических на один физический", b3..0 - двоичный логарифм количества логических в физическом
* слово 209 - b15==0, b14==1, b13..b0 - Logical sector offset within the first physical sector where the first logical sector is placed.

То есть для такого диска при логическом 512 байт и физическом 4K должно быть:

* uint16_t identify[256];
* identify[106] == 0x6003 - во всех случаях
* identify[209] == 0x4000 - если границы физических и логических совпадают с начала диска
* identify[209] == 0x4001 - если применён хак с началом физического сектора с логического 63-го для совместимности с разметкой MSDOS (WDxxEARS: для этого ставится джампер)

При этих настройках диск продолжает быть совместимым со старым подходом по всему функционалу, только теряя в скорости на невыровненных доступах.

Для SCSI, такие данные могут быть получены командой "READ CAPACITY (16)". См. sg_readcap из sg3_utils.


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

Через год (ой не верю - реально им этого чем через 4 года не разрешат) хотят перейти на 4KB блоки уже на шине. Не нужно быть Кассандрой, чтобы предсказать размер и яркость искр от этого процесса.

BTW, если кто-то захочет поставить джампер для внутреннего логического смещения (тогда к каждому номеру блока, полученного с шины, добавляется 1 и 63-й становится 64-м и попадает на границу блока) - не советую. WD15EARS не уменьшает количество анонсированных блоков, но доступа к последнему не даёт, вешаясь на много секунд.

У кого есть SSD диски - прошу посмотреть идентификацию - рассказывает ли такой диск размер физического блока. Если он говорит про хотя бы 4KB, уже лучше. А если честные 128KB, совсем хорошо.

Ссылки по теме:
http://www.anandtech.com/printarticle.aspx?i=3691
http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux
http://www.osnews.com/thread?409410
http://www.gossamer-threads.com/lists/linux/kernel/1039308#1039308
http://www.osnews.com/story/22872/Linux_Not_Fully_Prepared_for_4096-Byte_Sector_Hard_Drives
http://bigsector.org/
http://www.wdc.com/en/products/advancedformat/
https://bugzilla.altlinux.org/show_bug.cgi?id=16000
http://forum.ixbt.com/topic.cgi?id=11:40637
http://www.fcenter.ru/online.shtml?articles/hardware/hdd/28121
http://www.ixbt.com/news/hard/index.shtml?12/77/59
http://www.thg.ru/storage/wd_4k_sector/index.html
http://www.mytechsupport.ca/forums/index.php?topic=12612.0

* SCSI: READ CAPACITY(16): байт 13 b3..0 - двоичный логарифм количества логических блоков в физическом; байт 14 b5..0 и байт 15 полностью - "LOWEST ALIGNED LOGICAL BLOCK ADDRESS".
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 19 comments