Вопрос в том, что в пуле будут диски с разными секторами. Ну а 512E я как понимаю умеют и в 4k. А можно ли заставить 512E работать в 4k, может чтото прописать можно у диска?

можно поменять размер сектора

можно поменять размер сектора

Как и где не подскажите?

Вопрос в том, что в пуле будут диски с разными секторами. Ну а 512E я как понимаю умеют и в 4k. А можно ли заставить 512E работать в 4k, может чтото прописать можно у диска?

если ему будет приходить всегда кратно 8 512б секторам и по выровненным адресам -- чем это отличаться будет от нативно 4к секторов? ничем.

Для 4k диска это запись в один сектор, для 512 это в 8 секторов. На сколько это разница во времени? Я не силен во внутренностях дисков.

Как и где не подскажите?

например на сигейтах можно с помощью тулзов seachest tools

Для 4k диска это запись в один сектор, для 512 это в 8 секторов. На сколько это разница во времени? Я не силен во внутренностях дисков.

Не для smr не должно быть большой разницы

с помощью hdparm тоже можно

Для 4k диска это запись в один сектор, для 512 это в 8 секторов. На сколько это разница во времени? Я не силен во внутренностях дисков.

и что? диск сразу видит что ему особо эмулировать 512б сектора не надо и не тормозит

Для 4k диска это запись в один сектор, для 512 это в 8 секторов. На сколько это разница во времени? Я не силен во внутренностях дисков.

Ну проведите блин тест просто прям на диске разным блоком и убедитесь

Их еще не купили, не на чем провести тесты

И нет свободных, чтобы проверить

Вопрос в том, что в пуле будут диски с разными секторами. Ну а 512E я как понимаю умеют и в 4k. А можно ли заставить 512E работать в 4k, может чтото прописать можно у диска?

Я ничего не прописывал, просто собрал пул с ашифт 12 и все. Хз есть ли у меня смесь 4к+512е, я уже не помню.

Для 4k диска это запись в один сектор, для 512 это в 8 секторов. На сколько это разница во времени? Я не силен во внутренностях дисков.

В общем волнуетесь за перформанс - побенчите перед сборкой. А с точки зрения обслуживания пула дальнейшего по факту нужно ставить ashift=12, иначе потом при замене дисков можете себе стрельнуть в ногу

В общем волнуетесь за перформанс - побенчите перед сборкой. А с точки зрения обслуживания пула дальнейшего по факту нужно ставить ashift=12, иначе потом при замене дисков можете себе стрельнуть в ногу

И так стоит ashift=12

Платформа боевая и критичная, потестить не удастся. Но что нить придумаю.

И так стоит ashift=12

повторюсь, если опасаетесь что будут проблемы выставьте для новых дисков размер сектора = 4 кб принудительно.

Платформа боевая и критичная, потестить не удастся. Но что нить придумаю.

возьмите 1 диск как приедет и погоняйте fio с 512 и 4к блоком просто

повторюсь, если опасаетесь что будут проблемы выставьте для новых дисков размер сектора = 4 кб принудительно.

@mnekin или если ничего делать не хотите - плюсую к Николаю

Платформа боевая и критичная, потестить не удастся. Но что нить придумаю.

Не надо ничего придумывать, ставьте ашифт=12 и в бой, все равно 512е диски пишут и читают в режиме 4к, просто там все чуть сложнее. Но даже при сложности на скорости чтения это никак не отразится, а с записью диск сам разберется.

512е диски при чтении физически считывают 4к сектор, затем бьют его на куски по 512 и отдают ОС нужный кусок. На скорость чтения никак такая процедура не влияет, т.е. все решается современными буферами в 128-256МБ.

При записи 512е диск считает 4к целиком, разобьет на 8х512(исправил), выберет те 512 которые уже записаны (например если записано 2 блока по 512 то их он и выберет), допишет к ним новые 512 (допустим мы хотим записать еще 2 блока по 512), сформирует новый блок 4к и зафигачит все на винт.

Мне мыслится, если указать ашифт=12 для 512е диска, то он будет читать и писать блоками по 4к, как будто это был бы нативный диск 4к, просто в промежутке он возможно будет блок 4к бить на 4х512, а потом собирать и разбирать его. Но т.к. мы ему будем подавать куски по 4к, то процедура чтения и записи(где он там бьет 4 на 8х512(исправил) и дописывает куски в 512) будет упрощена до банального - разбили/собрали так и записали.

При записи 512е диск считает 4к целиком, разобьет на 8х512(исправил), выберет те 512 которые уже записаны (например если записано 2 блока по 512 то их он и выберет), допишет к ним новые 512 (допустим мы хотим записать еще 2 блока по 512), сформирует новый блок 4к и зафигачит все на винт.

я думаю что ничего он не допишет, в чате уже обсуждали проблему при работе с 512e дисками, ashift=12 и zvol

Так что никаких потерь в производительности быть не должно, я по крайней мере не видел.

дикий перерасход места, и от этого как раз спасает принудительное выставление размера сектора в 4к и zvol block size больше дефолтового, например в 16кб или в 32 кб

что безусловно может повлиять на перформанс

я думаю что ничего он не допишет, в чате уже обсуждали проблему при работе с 512e дисками, ashift=12 и zvol

ну так и я думаю что ничего он дописывать не будет если мы будем ему подавать сразу блоки по 4к, просто по логике работы таких дисков, в промежутке он может разобрать и собрать эти 4к на 8 кусков по 512 и не более, а писать он и будет физически блоками по 4к, как и задумано.

ну так и я думаю что ничего он дописывать не будет если мы будем ему подавать сразу блоки по 4к, просто по логике работы таких дисков, в промежутке он может разобрать и собрать эти 4к на 8 кусков по 512 и не более, а писать он и будет физически блоками по 4к, как и задумано.

ну во первых не на 4 а на 8, 512*4=2кб. во вторых это накладные расходы, в том числе и по перформансу

дикий перерасход места, и от этого как раз спасает принудительное выставление размера сектора в 4к и zvol block size больше дефолтового, например в 16кб или в 32 кб

откуда перерасход если он пишет блоками по 4к, группируя блок по 512

ну во первых не на 4 а на 8, 512*4=2кб. во вторых это накладные расходы, в том числе и по перформансу

ну да 8 блоков по 512, мой косяк, тупанул

ну во первых не на 4 а на 8, 512*4=2кб. во вторых это накладные расходы, в том числе и по перформансу

предполагаю что инженеры не дураки и заложили импакт в процессор контроллера и размер буфера

откуда перерасход если он пишет блоками по 4к, группируя блок по 512

оттуда, что при условной записи блочка в 512байт будет выделяться 4к сектор

и в raidz2 например таких блоков по 4к будет выделено 3 штуки

и в raidz2 например таких блоков по 4к будет выделено 3 штуки

стоит оговариваться, что да, в raidz эффективность хранения связана с размером ashift

стоит оговариваться, что да, в raidz эффективность хранения связана с размером ashift

согласен, но мы как раз рассматриваем случай с ashift=12

согласен, но мы как раз рассматриваем случай с ashift=12

у топикстартера мирроры

мы ща всё в кашу смешаем)

для мирроров hdd хорошая практика - всегда ставить ashift=12

а для ssd - 13, уж слишком часто они врут

оттуда, что при условной записи блочка в 512байт будет выделяться 4к сектор

да, но писаться частично, это заложено в логике работы таких дисков, это не моя задумка, я читал это в доке толи у ХП то ли у Делл - он берет 4к блок, бьет на куски по 512, считывает уже записанные куски, к ним дописывает новые куски по 512 либо пока блок 4к не закончится, либо пока куски не закончатся, формирует новый блок 4к и физически пишет на диск.

у топикстартера мирроры

видимо пропустил.. но насчет практики - ashift=12 также норм для raidz, при условии выполнения некоторых условий. причем в случае dataset с дефолтовым record size=128к это вообще не влияет, при использовании zvol нужно просто поменять vol block size на больший.

видимо пропустил.. но насчет практики - ashift=12 также норм для raidz, при условии выполнения некоторых условий. причем в случае dataset с дефолтовым record size=128к это вообще не влияет, при использовании zvol нужно просто поменять vol block size на больший.

да, но стоит учитывать явно, ага

Так что и чтение и запись все равно физически идет блоками по 4к до полного заполнения блока, потери будут только если мы не заполним блок 4к целиком, но это будет точно так же и при нативном 4к диске - если нам надо записать 10к на диск, то и на диске 512е и 4к он займет 2 блока по 4к + половина блока 4к, т.е. потери будут идентичными

уже обсуждался вопрос увеличения дефолтного volblocksize кстати, думаю продавим

до 16ти

Так что и чтение и запись все равно физически идет блоками по 4к до полного заполнения блока, потери будут только если мы не заполним блок 4к целиком, но это будет точно так же и при нативном 4к диске - если нам надо записать 10к на диск, то и на диске 512е и 4к он займет 2 блока по 4к + половина блока 4к, т.е. потери будут идентичными

ну как.. либо мы минимально можем записать 512 байт, либо 4кб - есть разница. в одном случае у тебя в 4к сектор может быть записано только 512 байт, в другом 2 кб - оверхед в 4 раза меньше же.

а вообще интересно - zfs же не учитывает внутреннюю логику работы контроллера диска и не может упорядочить каким либо образом уже записанные данные (дефрагментация не поддерживается). есть к чему стремиться. нетапп например умеет процедуру compaction, когда блоки записанные частично могут быть объединены в один 4кб блок. очень полезная фишка для cow fs

ну как.. либо мы минимально можем записать 512 байт, либо 4кб - есть разница. в одном случае у тебя в 4к сектор может быть записано только 512 байт, в другом 2 кб - оверхед в 4 раза меньше же.

Ну так какая разница диск это 512е или 4к натив, и там и там при записи одного одиночного куска в 512 мы сожрем 4к блок. Т.е. потери будут идентичны. А вот импакт в производительности не в пользу 512е будет, т.к. там будет дополнительный алгоритм будет работать RMW вроде так называет - чтение - модификация-запись, но импакт будет если идет работа с кусками не кратными 4к, т.е. больше или меньше. Вот ашифт=12 должен помочь с этой проблемой

Т.е. при ашифт=12 зфс будет диску скармливать блоки по 4к, он их будет хавать и так же пихать блоками 4к физически на диск, просто попутно разбирая на 8 блоков по 512 и обратно собирая, и больше ничего не делая, т.к. у него готовый кусок в 4к. Проблема как я писал выше будет лишь с блоками меньше или больше 4к, но только с запись. Импакта на потери дискового пространства или на чтение не будет.

А команды скази предусматривают запись не посекторально, а целым куском, чтоб диск сам решил, как ему записывать?

Т.е. при ашифт=12 зфс будет диску скармливать блоки по 4к, он их будет хавать и так же пихать блоками 4к физически на диск, просто попутно разбирая на 8 блоков по 512 и обратно собирая, и больше ничего не делая, т.к. у него готовый кусок в 4к. Проблема как я писал выше будет лишь с блоками меньше или больше 4к, но только с запись. Импакта на потери дискового пространства или на чтение не будет.

все верно, но как я понимаю если для диска 512e принудительно выставить sector size = 4к - в этом случае накладных расходов на rmw будет на порядок а то и два меньше. а это все performance impact

А команды скази предусматривают запись не посекторально, а целым куском, чтоб диск сам решил, как ему записывать?

гм.. по моему диск внутри себя никак кроме как по секторам писать не может..

А команды скази предусматривают запись не посекторально, а целым куском, чтоб диск сам решил, как ему записывать?

я так понял из доки, диск сам делает всю промежуточную работу по сборке/разборке блоков 4к, если он 512е.

Ну внутри то да.

Хм. Провести бы тесты, аж интересно стало

гм.. по моему диск внутри себя никак кроме как по секторам писать не может..

все верно если он 512е он все равно внутри пишет и читает физически блоками 4к, а в куски по 512 он превращает это уже уровнем выше - через контроллер

все верно если он 512е он все равно внутри пишет и читает физически блоками 4к, а в куски по 512 он превращает это уже уровнем выше - через контроллер

при ashift=12 да

Нашел доку о которой говорил

https://i.dell.com/sites/csdocuments/Shared-Content_data-Sheets_Documents/en/512e_4Kn_Disk_Formats_120413.pdf

тут подробно описано как работает 512е диск

https://i.dell.com/sites/csdocuments/Shared-Content_data-Sheets_Documents/en/512e_4Kn_Disk_Formats_120413.pdf

Спасибо! Схоронил.

Старница 5

с картинками в цвете =)

Спасибо! Схоронил.

сам почитаю, надо бы освежить память, но вот когда-то я читал ее и для себя сделал вывод - что диски 4к что 512е я в зфс загоняю с ашифт=12

https://i.dell.com/sites/csdocuments/Shared-Content_data-Sheets_Documents/en/512e_4Kn_Disk_Formats_120413.pdf

ага, полезно, почитаем. забавно то, что dell диски не производит))

ага, полезно, почитаем. забавно то, что dell диски не производит))

но они кастомизируют прошивку для оэм дисков, в том числе могут менять логику работы дисков, а вот вся магия преобразований 512е дисков как раз там и творится

А кто нибудь не ковырял их емс прям низкоуровнево?

но они кастомизируют прошивку для оэм дисков, в том числе могут менять логику работы дисков, а вот вся магия преобразований 512е дисков как раз там и творится

вот это сомнительно, не думаю что кто-то из oem поставщиков глубоко модернизирует прошивку контроллеров hdd. насчет ssd еще могу допустить

и то мало вероятно. пример трабла с ssd у hp, cisco и того же dell с ограничением по кол-ву часов наработки, или как оно там правильно называлось

вот это сомнительно, не думаю что кто-то из oem поставщиков глубоко модернизирует прошивку контроллеров hdd. насчет ssd еще могу допустить

как нет, если у меня в хпшных dl380 стоят сигейты с прошивкой от хп, причем прошивка так сильно кастомизированна, что точно такой же чистый сигейт сервером не просто не хавается, а еще и сам сервер в ступор приводит, начиная от показаний датчиков температур и заканчивая логикой работы

как нет, если у меня в хпшных dl380 стоят сигейты с прошивкой от хп, причем прошивка так сильно кастомизированна, что точно такой же чистый сигейт сервером не просто не хавается, а еще и сам сервер в ступор приводит, начиная от показаний датчиков температур и заканчивая логикой работы

там меняется пара килобайт кода на которые смотрят sas контроллеры от hp

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

там меняется пара килобайт кода на которые смотрят sas контроллеры от hp

не на всех

поставь в такой сервер обычный lsi/broadcom и онбудет хавать все диски без проблем. проверено не раз

поставь в такой сервер обычный lsi/broadcom и онбудет хавать все диски без проблем. проверено не раз

будет, а вот с хпшным контроллером будут проблемы

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

еще раз - это проблема при использовании урезанных контроллеров, всяких там perc и иже с ниме

т.е. модификация прошивки все же есть, вопрос только в модели диска и глубине модификации, но тут я хз, че они там делают, меняют ли алгоритмы под свои нужды, думаю в каких-то моделях меняют

будет, а вот с хпшным контроллером будут проблемы

так это не проблема дисков, а проблема с урезанным по логике контроллером, который требует этих самых модифицированных 2 кб кода в прошивке

так это не проблема дисков, а проблема с урезанным по логике контроллером, который требует этих самых модифицированных 2 кб кода в прошивке

Так я нигде не говорил что с дисками или контроллером проблема, я привел это как пример того что оригинальную фирмварь от сигейта/вд/хитачи хп или делл модифицируют под свои нужны (ну и конечно жадность), и кто его знает в каких дисках и на сколько глубоко

т.е. модификация прошивки все же есть, вопрос только в модели диска и глубине модификации, но тут я хз, че они там делают, меняют ли алгоритмы под свои нужды, думаю в каких-то моделях меняют

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