Хелп ZFS. Какой ashift для samsung ssd при создании пула?

Меньше 12 смысла ставить нет, больше требуется только для узкоспециализированных задач.

Тебе для чего?

Тебе для чего?

Zfs накатить. Везде юзаю ashift=12, но в нескольких местах видел, что бываю самсунги с сектором 8K, тогда нужен ashift=13, иначе скорость записи теряю вдвое. Вот и решил уточнить, потому как бенчить самостоятельно мне не досуг.

Тебе для чего?

Виртуальные машины.

Посмотри какие есть. У меня другой NVMe, тоже 512 было. Но:

sudo smartctl -a /dev/nvme0

...
Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 -     512       0         3
 1 +    4096       0         1
...

Убедись что есть, если есть - значит переключаемо. Не помню как, nvme format что-то там. man nvme и гугл в помощь.

P.S. Rel_Perf 3 = «Degraded», 2 = «Bad», 1 = «Good».

Ну как минимум больше стоит ставить, если сектор больше. У гнусмасов бывает 8192. Если оставить 4096, то не будет выравнивания, что может приводить к косякам с TRIM, и двум записям в один блок, когда можно обойтись одной, что приводит к износу и потере производительности.

У меня другой NVMe

Мои ssd sata3.

У гнусмасов бывает 8192

Знать бы у каких конкретно )

А, это именно SATA SSD. Тогда хз.

У NVMe. Какой именно линейки -хз.

Во чо нашел:

"В реальном мире такой штраф бьёт по твёрдотельным накопителям Samsung EVO, для которых должен действовать ashift=13, но эти SSD врут о своём размере сектора, и поэтому по умолчанию устанавливается ashift=9. Если опытный системный администратор не изменит этот параметр, то этот SSD работает медленнее обычного магнитного HDD.

Для сравнения, за слишком большой размер ashift нет практически никакого штрафа. Реального снижения производительности нет, а увеличение неиспользуемого пространства бесконечно мало (или равно нулю при включённом сжатии). Поэтому мы настоятельно рекомендуем даже тем дискам, которые действительно используют 512-байтовые секторы, установить ashift=12 или даже ashift=13, чтобы уверенно смотреть в будущее."

Сделаю ashift=13, хуже точно не будет.

Zfs накатить.

Для чего тебе ZFS?

в нескольких местах видел, что бываю самсунги с сектором 8K

ashift можно выставлять сколь угодно больше размера логического сектора, но не меньше (ибо ты не только теряешь скорость записи, но и быстрее изнашиваешь ячейки — посылая условные 512B, оно всё равно будет писать целый блок, условные 4K, например).

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

Тебе для чего?

Виртуальные машины.

Вот так бы сразу. Для повышения производительности можешь выставить ashift в 13 или даже 14 (8K или 16K соответственно). Но ящитаю, держать виртуалки на SSD не целесообразно, его лучше использовать как L2ARC.

Само собой не стоит ставить ashift меньше логического блока (я там выше расписал уже), но и больше ставить тоже нужно далеко не всегда.

Для ZFS, в которой размер блока 128k, это не имеет особого смысла.

держать виртуалки на SSD не целесообразно, его лучше использовать как L2ARC.

HDD в прошлом, как сторадж для ВМ использую ssd попроще, для L2ARC и ZIL надежные и быстрые с MLC.

Для ZFS, в которой размер блока 128k, это не имеет особого смысла.

Недопонял, что конкретно не имеет смысла?

blocksize и ashift - это разные параметры, если что.

Если опытный системный администратор не изменит этот параметр, то этот SSD работает медленнее обычного магнитного HDD.

Какая же гадость эта ваша ZFS.

blocksize и ashift - это разные параметры, если что.

Топик не читай, сразу отвечай. Скажем так, я знаю о zfs всё, вопрос был о том КАКОЙ РАЗМЕР СЕКТОРА НА SSD Samsung :)) Мне зачем то начали рассказывать об ZFS.

Какая же гадость эта ваша ZFS.

Как бы единственная нормальная ФС.

Так а я и не тебе отвечал :)

Наоборот, FS очень хорошая (особенно в надёжности данных), скорости не максимальные, но лично у меня а проде уже под 10 лет много где.

А тут проблема в железе, которое рапортует о себе некорректные данные для совместимости.

Кстати 860 pro тоже рапортует 512/512 о себе.

Так а я и не тебе отвечал :)

Да, точно, пардон муа :)

Оно не принято в ядро, так что хорошим быть не может.

Конечно, не принято, лицензии не совпадают вообще. dkms в помощь.

Может случиться оказия, когда нужно срочно обновить ядро (устранение уязвимости), но новая версия не совместима с патчем zfs. Приплыли.

Прохладная история, за 10 лет такого даже близко не было :)

Прохладная история

Прохладно будет, когда такое на проде случится.

когда нужно срочно обновить ядро (устранение уязвимости)

И много у нас таких «срочно» было за всю историю? имхо не очень много. Да и вариант, что патч каким-то образом повлияет на zfs тоже видится не очень сильно вероятным. Скорее уж в самом модуле zfs найдут дыру.

Баги находят не в «сферическом ведре», а в конкретных частях ведра. Например нашли баг в cifs, а он вам ну ниразу не нужен, какое вам до этого бага дело? Плюс вспоминаются случаи когда достаточно было сделать, что-то виде echo «la-la-la» > /proc/.... для того, что бы баг уже не работал.

Не случится по двум причинам:

1. Уязвимости исправляют в минорных патчах, которые не ломают совместимость.

2. В прод не суют ядра с kernel.org.

В прод не суют ядра с kernel.org.

Шапочник?

Шапочник?

Шапочник, бубунтоид, дебиановец, зюзевод, да кто угодно.

Не, ну у меня тоже был прод на Slackware, но это было местами больно :)

но это было местами больно

Встречается такое... но редко.

Недопонял, что конкретно не имеет смысла?

Размер физической страницы флэша и выравнивание.

Так как физический носитель отдаёт размер блока 512 байт (а на самом деле страница может быть и 4k байт, и 16k байт — ты этого не узнаешь НИКОГДА, если не проведёшь тестирование), то ФС с гораздо большим логическим блоком «вместит» десятки этих страниц, даже если какие-то из них на краях блока окажутся «срезанными» соседним блоком ФС — это практически не влияет на скорость записи, а тем более считывания информации с такого «врущего» носителя. Разве что с секундомером стоять над ним и измерять малейшие погрешности времени записи/освежения информации, которая будет с некоторой задержкой на страницах, одновременно расположенных на соседних блоках ФС — такие страницы подлежат TRIM только при условии, что оба соседствующих блока ФС будут очищены. То есть проблема с очисткой страницы будет только при удалении данных в «концевом» блоке из всей цепочки блоков хранения удаляемого файла, граничащего с блоком ФС, которые не принадлежит этому файлу. Поскольку ZFS это CoW, то проблема отложится надолго и затронуть свежезаписанные файлы вряд ли сможет — и то, если ФС исчерпывает свободное пространство.

Почему вы не хотите довериться производителю, который произвёл данный носитель информации? Если он рапортует, что у носителя блоки по 512 байт, то и пусть — алгоритмы внутренней очистки и освежения, видимо, этот момент учитывают. Со стороны ФС есть протокол TRIM, и ничего более ей знать не положено, а если положено, то это автоматически учитвается разработчиками современных ФС (которые должны быть в курсе о таких вот аппаратных решениях).

Так как физический носитель отдаёт размер блока 512 байт

Объясните мне, пожалуйста, как создается пул без указания ashift? Пул получается с неким default 0, что это значит?

Объясните мне, пожалуйста, как создается пул без указания ashift?

Как создаётся? На каждый vdev операционня система выдаёт утилите zpool create индивидуальное значение ashift, соответствующее размеру сектора, о котором рапортует физическое устройство. Утилита zpool create учитывает это значение.

Тестирование: Про ZFS, Advanced Format и ashift

Как создаётся? На каждый vdev операционня система выдаёт утилите zpool create индивидуальное значение ashift, соответствующее размеру сектора, о котором рапортует физическое устройство. Утилита zpool create учитывает это значение.

Некий ashift конечно есть, но по zfs get показывает ashift=0, что это значит?

Мой опыт не сталкивался с таким. У пула можно это свойство прочитать (оно действительно равно нулю), у файловой системы — нет.

Может 128k-блок ZFS отображается в 128k-сектор носителя?

Может 128k-блок ZFS отображается в 128k-сектор носителя?

Я не знаю, вы здесь признанный специалист.