диски с 4K блоками
Feb. 28th, 2010 07:55 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
netch80Те, кто читают жёлтую прессу, знают, что на нас неумолимо надвигаются диски с 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".
На днях коллега купил такого зверя, и мы стали его исследовать. В основном интересовало, что сделать, чтобы не нарваться на постоянное пересечение границ и соответствующее снижение производительности. Здесь оказался более-менее внятный метод:
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".
