https://www.solaris-cookbook.eu/solaris/solaris-10-zfs-evil-tuning-guide/

Эта ссылка давно недоступна

Эта ссылка давно недоступна

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

В общем я тут начитался всякой инфы о том как работает зфс и у меня родился план как попробовать минимизировать явление фрагментации. Короче на сколько я понимаю избежать фрагментации невозможно впринципе, но можно попробовать её уменьшить, у меня мысль такая: откуда берется фрагментация? В основном по одной и той же причине, удаление старых файлов оставляет дырки в сплошном потоке данных и в эти дырки затем записываются более крупные файлы из-за чего получаются фрагменты. Как уменьшить количество фрагментов? Подобрать оптимальный размер блока, проанализировав не средний размер файлов, а нормальное распределение их размеров, и определить какого размера файлов больше всего и исходя из этого подобрать размер блока. Это первый нюанс. Второе, скорее всего увеличению фрагментации способствует сжатие, оно делает мелкие блоки, оставляя после удаления мелких файлов очень мелкие дырки. Думается мне, что сжатием можно пренебрегать, поскольку сами блобы не сжимаются в принципе, у них слишком большая энтропия, но, взамен мы получим относительно крупные дырки (например 512кб) что уже делает фрагментацию не такой страшной как если бы фрагменты были по 32 или 64кб или ещё мельче. И ещё один бонус: со стабильно крупным размером блока можно забить на рекомендацию оставлять в пуле 15-20% свободного места для избежания, деградации производительности, что само по себе поможет нивелировать эффект отключения сжатия. Вот такие мысли.

В общем я тут начитался всякой инфы о том как работает зфс и у меня родился план как попробовать минимизировать явление фрагментации. Короче на сколько я понимаю избежать фрагментации невозможно впринципе, но можно попробовать её уменьшить, у меня мысль такая: откуда берется фрагментация? В основном по одной и той же причине, удаление старых файлов оставляет дырки в сплошном потоке данных и в эти дырки затем записываются более крупные файлы из-за чего получаются фрагменты. Как уменьшить количество фрагментов? Подобрать оптимальный размер блока, проанализировав не средний размер файлов, а нормальное распределение их размеров, и определить какого размера файлов больше всего и исходя из этого подобрать размер блока. Это первый нюанс. Второе, скорее всего увеличению фрагментации способствует сжатие, оно делает мелкие блоки, оставляя после удаления мелких файлов очень мелкие дырки. Думается мне, что сжатием можно пренебрегать, поскольку сами блобы не сжимаются в принципе, у них слишком большая энтропия, но, взамен мы получим относительно крупные дырки (например 512кб) что уже делает фрагментацию не такой страшной как если бы фрагменты были по 32 или 64кб или ещё мельче. И ещё один бонус: со стабильно крупным размером блока можно забить на рекомендацию оставлять в пуле 15-20% свободного места для избежания, деградации производительности, что само по себе поможет нивелировать эффект отключения сжатия. Вот такие мысли.

@gmelikov, а что вы всё-таки имели в виду под "со сжатием, если тип данных не меняется, логика не верная, т.к. сжатие будет примерно одинаковым коэффициентом"

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

Поэтому я и писал что нужно нормальное распределение прикинуть

Отпишись потом об успехах :) чего дали все эти приседания)

Я думаю они достаточно рандомные

а сжатие, если в цпу не упирается, я бы даже на несжимаемых данных включал. Сейчас zfs не запишет сжатым блок, если он не сжался хотя бы на 12.5%, зато можно поставить хоть recordsize=16M и экономить на последних блоках

Линейный сторадж это что?

Ему же вроде мало 6 дисков будет

нет, три RAID1

Тогда объем станет 12 Тб. Может оказаться мало в перспективе. В целом, RAIDZ x 2 чуть менее надёжный получится. Но каких-то других критических отличий нет ?

RAIDZ1 может дать больших проблем, если не повезёт.

Обычные рейды без чексумм например в случае пятёрки и больших дисков никогда не соберутся после сбоя.

Подскажите, насколько актуален совет: У меня есть 6 дисков по 4 Тб. Совет говорит что лучше сделать RAIDZ x 2: zpool create -f myzpool raidz hd1 hd2 hd3 \ raidz hd5 hd6 hd7 чем один RAIDZ2: zpool create -f myzpool raidz2 hd1 hd2 hd3 hd4 hd5 hd6 Первый выигрывает в скорости и чуток в объеме. Что скажите ? насколько это действиетльно полезно ?

Коллеги, является ли на сегодня нормальной практикой использовать mirrored 2 x SSD одновременно для SLOG + L2ARC (две разные partitions)?

Коллеги, является ли на сегодня нормальной практикой использовать mirrored 2 x SSD одновременно для SLOG + L2ARC (две разные partitions)?

сколько памяти на хосте и размер пула?

4Gb - RAM и при этом пул на 20Тб? Даже с L2ARC это будет жестоко. Если есть возможность - добавляйте RAM и только когда уже нет возможности добавляйте L2ARC. Если памяти много, то лучше на ssd вынести SLOG и special vdev. Тем более что у вас зеркало из ссд Но по сути вопроса - можно держать и на одном ссд, они сейчас быстрые (я надеюсь что у вас такой) и поэтому одновременный доступ не будет являться узким местом