ну так я и говорил что у тебя ашифт 9 не может в 4кн, там вниз нельзя

Сильно роняет производительность это интересно 🤔

в смысле ты может шифт 512 байт использовать с сектором 4к но не назад

в рандоме должно падать не думаю что очень сильно

А вот улучшить ли ситуацию hba 12gb на 6g полках интересно 🤔

Да, я понял Вот их даунгреданули и все ок 👌оказывается lsi 9200 старый их видит :)))

ну оно же не в скорость интерфейса упирается

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

Ну как бы между netac и Intel к примеру )))) Мими

Это вам надо на профильное образование в ВУЗ. Узнать, как malloc работает, как и зачем устроена TLB.

RAIDZ3 делать и можно и нетак юзать, если всегда под рукой есть пара подменных. Я вот щас вообще из хиквижина собирать буду массив, потому что микрон охренели и под видом TLC пихают теперь QLC...

Я опять начитался фигни, помогите пожалуйста. Раньше я думал, что фрагментация существует только в hdd - там крутится головка - долго. Но сейчас я вычитал, что существует фрагментация не только ssd но и рам! как это? с внутрненней фрагментацией всё понятно  - страница 4 кб, а заняли только 2 - вот тебе и пустое место. А чему может мешать внешняя фрагментация? всёравно ко всему обращение O(1), какая разница где что лежит. И зачем тогда huge packages. Я прочитал что они полезны не только для сервера с бд с большой нагрузкой (где раздел с бд сделан с блоками под размр hp), но и для уменьшеня фрагментации + нагрузки на транслятор в физическую память. Сейчас я совсем запутался - вот и пришёл сюда. Не совсем про zfs вопрос, но этот чат ближе всего к теме вопроса.

фрагментация кусочков физпамяти по 4к есть (или по 2мб если huge pages). но в типичном случае она совершенно по барабану т.к. в вирт память отмаплена ММУ. ну если там ядру понадобится вдруг непрерывная физпамять то могут быть проблемы. но опять же изза мму ось может провернуть (и проворачивает) дефрагментацию ф з памяти совершенно незаметно для софтов. в целом, можно не париться

фрагментация кусочков физпамяти по 4к есть (или по 2мб если huge pages). но в типичном случае она совершенно по барабану т.к. в вирт память отмаплена ММУ. ну если там ядру понадобится вдруг непрерывная физпамять то могут быть проблемы. но опять же изза мму ось может провернуть (и проворачивает) дефрагментацию ф з памяти совершенно незаметно для софтов. в целом, можно не париться

Да, я понял что можно не париться (всё работает - не трогай), просто я самого явления не понимаю - внешняя фрагментация. Что мешает просто записывать информацию постранично в свободные бооки? ко всему же доступ O(1), тогда какая внешняя фрагментация может быть?

Это не про странички, когда всё одинакового объёма. Это скорее про malloc. И вот там - запросто

Я прочитал про это но всё-равно не понял. есть 3 способа вставки в память. Лучший, первый попавшийся и худший. Но что значит лучший? это когда блоки записываються друг за другом? а в чём смысл этого, если ко всему скорость обращения одинакова?

Это не про странички, когда всё одинакового объёма. Это скорее про malloc. И вот там - запросто

маллок это сугубо проблемы процесса чо он там себе в вирт памяти нафрагментировал. кому не нравится пусть на жабе пишут )

Смотри, есть у тебя 4к памяти, ты выделил четыре блока по 1к. Потом удалил первый и третий. Итого - у тебя 2к свободно, но выделить непрерывно 2к ты не сможешь.

В чём проблема внешней дефрагментации будет проявлятся? Зачем мне выделять их неприрывно? Пока писал кажется понял. Некоторой информации неважна очерёдность страниц. То есть например tuple размером гигабайт сможет спокойно лежать в блоках по 4к разбросанных по всей памяти. А вот с вектором будут проблемы. Точно также как и когда из 4 килобайт осталосся 1, и нужно всунуть вектор на 1.5кб. В случае если есть рядом пренадлежащий памяти блок, то я просто сую, а если нет - то придётся записывать в следующий блок и получится внутренняя дефрагментация Хотя нет, не понял. У процесса же создаётся своё адресное пространство, почему она в него не может положить вектор как-бы очерёдно, а в памяти оно будет лежать в разных местах

Ну вот нужен маллоку блок памяти 2к, причина не важна. А целого - нет, только кусочки.

Выступал на питерском хайлоаде про ZFS https://highload.ru/spb/2023/abstracts/10158 Уже видео появилось https://www.youtube.com/watch?v=x2XYOOiyhSc

на основе доклада подготовили статью https://habr.com/ru/companies/vk/articles/770300/ , буду рад фидбеку (и косякам в личку :) )

Почитал. Достаточно разжевано для новичка написано. У меня остаётся вопросы: * Будет ли отдельный дефрагментатор? * Будет ли размазыватель данных по дискам, если в пул добавили новое зеркало дисков?

> * Будет ли отдельный дефрагментатор? не планируется > * Будет ли размазыватель данных по дискам, если в пул добавили новое зеркало дисков? автоматический на фоне - тоже нет, НО это и так происходит на любой (пере)записи данных

Не, никакой автоматики - один раз размазал данные по дискам и все

про cp --reflink=always тоже ничего не сказано

и вопрос который я опять задам -- таковое между датасетами работать умеет/будет?

> * Будет ли отдельный дефрагментатор? не планируется > * Будет ли размазыватель данных по дискам, если в пул добавили новое зеркало дисков? автоматический на фоне - тоже нет, НО это и так происходит на любой (пере)записи данных

вручную возможно сделать, просто перезаписав удобным образом данные, на уровне самой ФС планов нет

А ведь для расширения рейда нечто подобное сделали, эх

да, если без шифрования

то есть даже несмотря на то, что zfs форсит любой датасет быть точкой монтирования? тогда вопрос -- а как именно?

не совсем, и там для этого считай доп слой нагородили маппинга данных

там обсуждали возможные проблемы с этим, емнип если cp --reflink=auto юзать то нужный сисколл полетит и отработает, а вот с always там и правда трабла с маунтпоинтами была

то есть с auto это как-то в обход линуксовой vfs пойдет что ли?

always и auto по разному просят ядро, на гитхабе проскакивало где-то описание

спасибо на самом деле, я не знал. буду пробовать как на 2.2.х перейду )

❓Вопрос знатокам Много попадалось предупреждений, что при заполнении пула более 80% начинается деградация производительность zfs, и уж 5% точно нужно держать свободными. Но недавно (в непрофильном чате, но реально использующие zfs люди) мне сказали, что это старая информация, и современные версии не теряют производительность с заполнением диска. Что скажут в профильном чате - где правда? Сценарий использования: STORJ, то есть постоянная запись большого количества мелких (большинство < 1 МБ) файлов (старые через промежуточное хранение в корзине удаляются)

❓Вопрос знатокам Много попадалось предупреждений, что при заполнении пула более 80% начинается деградация производительность zfs, и уж 5% точно нужно держать свободными. Но недавно (в непрофильном чате, но реально использующие zfs люди) мне сказали, что это старая информация, и современные версии не теряют производительность с заполнением диска. Что скажут в профильном чате - где правда? Сценарий использования: STORJ, то есть постоянная запись большого количества мелких (большинство < 1 МБ) файлов (старые через промежуточное хранение в корзине удаляются)

❓Вопрос знатокам Много попадалось предупреждений, что при заполнении пула более 80% начинается деградация производительность zfs, и уж 5% точно нужно держать свободными. Но недавно (в непрофильном чате, но реально использующие zfs люди) мне сказали, что это старая информация, и современные версии не теряют производительность с заполнением диска. Что скажут в профильном чате - где правда? Сценарий использования: STORJ, то есть постоянная запись большого количества мелких (большинство < 1 МБ) файлов (старые через промежуточное хранение в корзине удаляются)

на 95% можно уже и клинч словить

на 95% можно уже и клинч словить

А в чем клинч проявляется? Чтение тоже блокируется, или только запись? Если только запись - то, может быть, будет саморегуляция (проигрывание в загрузке новых кусков, и через корзину освобождение места до приемлемой производительности)?

я тестировал запись. чтение то врядли сломается

❓Вопрос знатокам Много попадалось предупреждений, что при заполнении пула более 80% начинается деградация производительность zfs, и уж 5% точно нужно держать свободными. Но недавно (в непрофильном чате, но реально использующие zfs люди) мне сказали, что это старая информация, и современные версии не теряют производительность с заполнением диска. Что скажут в профильном чате - где правда? Сценарий использования: STORJ, то есть постоянная запись большого количества мелких (большинство < 1 МБ) файлов (старые через промежуточное хранение в корзине удаляются)

нынче "правило большого пальца" это 95%, НО: - 128G по дефолту зарезервированы дополнительно к отображаемому объёму https://github.com/openzfs/zfs/blob/799e09f75a31e80a1702a850838c79879af8b917/module/zfs/spa_misc.c#L351 - очень важно каким блоком идёт запись, хуже будет когда io pattern очень разнообразный, лучше - когда единообразный - ну и важен объём пула, чем он больше, тем больше каждый 1 процент пространста лично я на домашней хранилке уже раз 100 забивал в полочку пространство, и выкрутил slop на минимум, при котором обещается риск что пул может встать по возможности удаления, да и жил с менее 1% свободного пространства. Пул до сих пор работает, выдаёт всё те же иопсы hdd под ним. так то любую фс можно зафрагментировать оч сильно, всё зависит от io pattern

Во, и я дополню. Как лучше сделать - Zvol размером в 80% от пула, или размером в весь пул, но следить за его заполнением не более чем на 80%? Кажется, что первое разумнее - но вдруг

Во, и я дополню. Как лучше сделать - Zvol размером в 80% от пула, или размером в весь пул, но следить за его заполнением не более чем на 80%? Кажется, что первое разумнее - но вдруг

Ну вот паттерн у STORJ, видимо, самый неблагоприятный: из-за постоянного рандомного удаления маленьких файлов фрагментация, видимо, жуткая 🤯

Фрагментация.

вы посмотрите, кто ее автор!

местный админ

Бинго!

нужно ждать пока он сюда не запостит?

Сами найдете его сообщение?

Сами найдете его сообщение?

искал - не видел

Просто сказали бы "Я не смотрел и не умею пользоваться поиском"

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

Закреп видимо тоже?

Закреп видимо тоже?