Так все-таки, постгрес какими блоками пишет в фс?

Так все-таки, постгрес какими блоками пишет в фс?

8K таблицы, раньше было, если специально не пересобирать.

Если выставить recordsize больше, чем 8к, то будут писаться блоки по 8к в любом случае.

Если выставить recordsize больше, чем 8к, то будут писаться блоки по 8к в любом случае.

Хорошй вопрос, в студию 🙂 Мне кажется, что будет писать по размеру сжатой записи, кратной размеру блока устройства.

Вы имеете в виду размер ashift?

Вы имеете в виду размер ashift?

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

Вы имеете в виду размер ashift?

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

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

Just in case Фрагментация в zfs бессмысленное понятие

Для всех RoW систем это там

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

В документации написано, что блок меньшего размера, чем рекордсайз будет записан как есть, те не будет занимать в пуле 128кб. А так, вроде верно.

при поверхностном поиске, вот что выдала алиса: Как работает Размер блока зависит от размера файла: Если файл меньше или равен recordsize, он хранится как один логический блок его размера, округлённый до ближайшего кратного 512 байтам. Если файл больше recordsize, он делится на несколько логических блоков по recordsize каждый, при этом последний блок дополняется нулями до recordsize.

https://docs.oracle.com/cd/E26505_01/html/E37386/chapterzfs-db1.html

при поверхностном поиске, вот что выдала алиса: Как работает Размер блока зависит от размера файла: Если файл меньше или равен recordsize, он хранится как один логический блок его размера, округлённый до ближайшего кратного 512 байтам. Если файл больше recordsize, он делится на несколько логических блоков по recordsize каждый, при этом последний блок дополняется нулями до recordsize.

Wtf

видимо ashift=9

видимо ashift=9

Нет, это галлюцинация нейронки

Оно округляется до ближайшей степени 2

60кб округлятся до 64кб

К примеру, 66048 как бэ кратно 512, но никак не соотносится с реальностью

при поверхностном поиске, вот что выдала алиса: Как работает Размер блока зависит от размера файла: Если файл меньше или равен recordsize, он хранится как один логический блок его размера, округлённый до ближайшего кратного 512 байтам. Если файл больше recordsize, он делится на несколько логических блоков по recordsize каждый, при этом последний блок дополняется нулями до recordsize.

Любые ответы от ИИ, включая Алису, включая любую суммаризацию запрещены - нейронки часто додумывают того, чего нет.

Если не включать рейд к этому счастью Начнём с простого: (сжатие отключено, record size 128к) 5 файлов 500b 60k 120k 250k 500k По мнению df -h это будет занято 1152kb (128к*3+128*2+128*4) Поэтому верить df -h бессмысленно в отношении ZFS. Продолжаем. Object - номер объекта для прочих команд zdb lvl - уровень* файла iblk - это record size dblk** - конечный record size для этого элемента dsize*** - конечный размер элемента dnsize - размер dnode, по дефолту это 512б lsize - логический размер файла Количество блоков из которых состоит этот файл. На примере 500кб видно, что если recordsize больше 1, то появляется ещё мастер блок, который занимает 8кб Теперь, если файл уменьшить, с 5мб до 500кб, то появятся кучка пустых recordsize *уровень файла это его сложность. К примеру у файла состоящего из 1 recordsize это 1. Для 2+ это 2. **не может быть меньше 512б, или больше чем recordsize ***dsize это размер всех блоков, поэтому для файлов больше чем recordsize это будет размер recordsize+8kb (мастер блок)

%full это процент насколько файл заполнен нулями Тот факт, что файл может уменьшаться, является причиной, почему файл всегда занимает recordsize, это место только его и не может быть быть использовано другими ресурсами. Это всё при отключённом сжатии. Теперь, ситуация, если сжатие есть. Ситуация становится чуть интереснее, файл из нулей логично занимает ничего, ему даже блока не выделено. В тот момент как в нём появляется хотя бы один байт, И при использовании сжатия уже появляется деление на отдельные сегменты, они обусловлены тем, что пустые места в файле (0) не существуют для ZFS, поэтому для них не выделяется recordsize А вот если говорить про сжатие данных отличных от 0, то ситуация слегка отличается. Даже если файл абсолютно одинаков (в данном случае файл содержит в себе только байт DC - в итоге на ФС всё равно окажется блоков (recordsize) по размеру файла, но фактический размер файла уменьшиться (По этой причине бессмысленно создавать толстый zvol если включается сжатие)

при поверхностном поиске, вот что выдала алиса: Как работает Размер блока зависит от размера файла: Если файл меньше или равен recordsize, он хранится как один логический блок его размера, округлённый до ближайшего кратного 512 байтам. Если файл больше recordsize, он делится на несколько логических блоков по recordsize каждый, при этом последний блок дополняется нулями до recordsize.

tl;dr нейронка корректно сказала вот эту часть, но это влияет на итоговый размер файла примерно никак

tl;dr нейронка корректно сказала вот эту часть, но это влияет на итоговый размер файла примерно никак

Без учёта рейда

Потому что если используется рейд, то dsize (собственно размер, который занимает файл) уже зависит от паддинга и насколько красиво он ложится на количество дисков, а dblk особо не имеет значения судя по подсчётам свободного места

Больше можно тут почитать: https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSFilePartialAndHoleStorage

Спасибо

Так, что по тестам?

Поправил mitigations=off Это дало 5-10% прироста, что неплохо.

Более интересная картина, если добавить special устройство

Видно, что bandwidth предположительно метаданных превышает bandwith данных и съедает всю возможную полосу по записи моего nvme.

Скорость записи fio с блоком 4К при этом около 380 MB/S при 80kiops, что примерно бьется с размером блока 16КБ на volume

Скорость записи fio блоком 16k тоесть равным размеру блока диска составил 1200MB/S при тех же 80kiops, то есть понятно, что полезных данных пишется в 4 раза больше, что тоже ожидаемо.

Ну а при записи блоками 64к объем записываемых метаданных начинает снижаться, в то время как объем записи данных повышается.

Продолжайте вести наблюдение

Продолжайте вести наблюдение

Ну мне было интересно, почему так все плохо с моим пулом, ответ я получил, ну и вопрос про количество записываемых данных, я вроде тоже примерно понял. К сожалению в сети не нашел данных по потреблению CPU и объему ввода-вывода. На этом наблюдение заканчиваю :)

Я понимаю, что zpool может не найти файлы, в которых были ошибки (например, если ошибки в метаданных) - но пул то СУЩЕСТВУЕТ (и реально работает) root@PC121 ~# zpool status w18.1 pool: w18.1 state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A scan: resilvered 1.84M in 00:00:03 with 0 errors on Sun Jun 1 22:03:34 2025 config: NAME STATE READ WRITE CKSUM w18.1 ONLINE 0 0 0 ata-WDC_WUH721818ALE6L4_3GG55YSE ONLINE 0 0 0 errors: 1977 data errors, use '-v' for a list НО: root@PC121 ~# zpool status -v w18.1 pool: w18.1 state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A scan: resilvered 1.84M in 00:00:03 with 0 errors on Sun Jun 1 22:03:34 2025 config: NAME STATE READ WRITE CKSUM w18.1 ONLINE 0 0 0 ata-WDC_WUH721818ALE6L4_3GG55YSE ONLINE 0 0 0 errors: List of errors unavailable: no such pool or dataset

всем привет. Нужна помощь зала ) в гугл ходил уже. Мне надо среплицировать данные. Это можно сделать через вэб морду, на скрине. Я отмечаю из каких заданий создания снапшотов использовать снимки (три задания ). Задался вопросом как это сделать руками в терминале. zfs send пул@снимок | zfs receive пул Как правильно прописать первую часть, которая zfs send ?

ну или задам так вопрос: Если создам ручной снимок для этого действия. Перенесу данные по этому ручному снимку. Снимки которые созданы были по заданиям перенесуться или нет ?

ну или задам так вопрос: Если создам ручной снимок для этого действия. Перенесу данные по этому ручному снимку. Снимки которые созданы были по заданиям перенесуться или нет ?

Добрый день. Лучше напишите, что хотите получить

Дома стоит трунас core. Второй такой же стоит в гараже. Гаражный на мобильной сети живет. У меня работал бэкап. Данные из дома реплицировались по заданию снимков (снимки создавались каждые три часа) в гараж. В заданиях снимков было указано время жизни "две недели". Но жизнь показала что это было моей ошибкой 😁 Короче вспышку профукал, когда чухнулся, прошел месяц, репликация не ожила. Т.к. данных 500 гигов и пересылать через мобильную сеть это извращение, хочу сделать как в прошлый раз. реплицирую на HDD, приезжаю в гараж, реплицирую в пул с диска и потом уже запускаю репликацию из дома в гараж напрямую. В прошлый раз не было снимков созданных ранее. Реплицировал первый снимок задания создания снимков. А сейчас есть куча снимков из трех заданий создания. Надеюсь меня поняли )

Через вэб морду это всё сделать элементрано, но мне надо чрез терминал это всё запустить.

Дома стоит трунас core. Второй такой же стоит в гараже. Гаражный на мобильной сети живет. У меня работал бэкап. Данные из дома реплицировались по заданию снимков (снимки создавались каждые три часа) в гараж. В заданиях снимков было указано время жизни "две недели". Но жизнь показала что это было моей ошибкой 😁 Короче вспышку профукал, когда чухнулся, прошел месяц, репликация не ожила. Т.к. данных 500 гигов и пересылать через мобильную сеть это извращение, хочу сделать как в прошлый раз. реплицирую на HDD, приезжаю в гараж, реплицирую в пул с диска и потом уже запускаю репликацию из дома в гараж напрямую. В прошлый раз не было снимков созданных ранее. Реплицировал первый снимок задания создания снимков. А сейчас есть куча снимков из трех заданий создания. Надеюсь меня поняли )

Привести из гаража сервер домой и спокойно по локалке синхронизировать.

Так тоже можно. Ключевое в этом всём для меня, определить какую команду выполняет вэб морда и забить ее руками в терминале.

bcachefs может стать похожей на zfs:) правда не в том свете в котором вы подумали https://t.me/yetanotherit/47

Дома стоит трунас core. Второй такой же стоит в гараже. Гаражный на мобильной сети живет. У меня работал бэкап. Данные из дома реплицировались по заданию снимков (снимки создавались каждые три часа) в гараж. В заданиях снимков было указано время жизни "две недели". Но жизнь показала что это было моей ошибкой 😁 Короче вспышку профукал, когда чухнулся, прошел месяц, репликация не ожила. Т.к. данных 500 гигов и пересылать через мобильную сеть это извращение, хочу сделать как в прошлый раз. реплицирую на HDD, приезжаю в гараж, реплицирую в пул с диска и потом уже запускаю репликацию из дома в гараж напрямую. В прошлый раз не было снимков созданных ранее. Реплицировал первый снимок задания создания снимков. А сейчас есть куча снимков из трех заданий создания. Надеюсь меня поняли )

zpool history должен подсказать историю команд, если через cli дёргаётся под капотом

Коллеги, у кого-то осталась копия статьи по использованию raidz массивов и табличка, как используется дисковое пространство: при каком кол-ве дисков, какой raidz, recordsize... Статья на английском, называлась как-то "Как перестать бояться zfs..." что-то типа такого.

Коллеги, у кого-то осталась копия статьи по использованию raidz массивов и табличка, как используется дисковое пространство: при каком кол-ве дисков, какой raidz, recordsize... Статья на английском, называлась как-то "Как перестать бояться zfs..." что-то типа такого.

оригинальную в вебархиве можно поискать, вот более короткая статья и та самая табличка (копия) https://openzfs.github.io/openzfs-docs/Basic%20Concepts/RAIDZ.html

Коллеги, у кого-то осталась копия статьи по использованию raidz массивов и табличка, как используется дисковое пространство: при каком кол-ве дисков, какой raidz, recordsize... Статья на английском, называлась как-то "Как перестать бояться zfs..." что-то типа такого.

https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz https://web.archive.org/web/20250000000000*/https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz

https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz https://web.archive.org/web/20250000000000*/https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz

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

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

VPN

VPN

...это зло :) кроме своего собственного.

...это зло :) кроме своего собственного.

Через SSH можно тоннель на скорую руку покинуть)

И расширение для браузера socks5 proxy

Можно просто Тор браузер запустить

спасибо за советы

Вопрос по механике: Если нвме поделить на несколько неймспейсов и в рейд0 соединить потом - будет больше иопсов?)

Вопрос по механике: Если нвме поделить на несколько неймспейсов и в рейд0 соединить потом - будет больше иопсов?)

Хм, в теории, учитывая, что zfs наплодит доп процессов на запись - да

Но немного

Может 5%

Может 5%

Не меряли, случаем, на нескольких отдельных дисках рейд0 сколько даёт по иопсам прибавки?

@DanteAvalon а как побенчить zvol корректно?

@DanteAvalon а как побенчить zvol корректно?

Делаешь nvme на два ns, делаешь из них zpool create nvme1 /dev/nvme0n1 /dev/nvme0n2 Ну а дальше что тебе больше надо, файлы/zvol

Делаешь nvme на два ns, делаешь из них zpool create nvme1 /dev/nvme0n1 /dev/nvme0n2 Ну а дальше что тебе больше надо, файлы/zvol

Да мне больше параметры fio интересны

Да мне больше параметры fio интересны

Ну так, какие тебе нужны значения Как вариант можно в лоб взять бенч Виталия

Только недавно прочитал, что не все модели nvme поддерживают разделение на namespace

Только недавно прочитал, что не все модели nvme поддерживают разделение на namespace

А мне наоборот казалось, что очень мало кто поддерживает :) Ещё реже SR-IOV

А мне наоборот казалось, что очень мало кто поддерживает :) Ещё реже SR-IOV

Всё верно. Могут не только лишь все, не каждый может это делать. (с)

А мне наоборот казалось, что очень мало кто поддерживает :) Ещё реже SR-IOV

Все Enterprise grade поддерживают