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

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

не надо zvol, достаточно просто датасет. В случае с LXD/докер и подобным если хочется заморачиваться тюнингом можно для конкретно мускля сделать датасет с 16к и кеш=метадата. Отлично всё работает

у меня больше 1Мб не позволяет ставить))

потому что надо специально разрешить - https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#larger-record-sizes

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

да уже в курсе), но спасибо), в прочем мне не пригодилось ставить больше

Никаких повреждённых таблиц, я указал, что оставляю метаданные. Они пишутся как sync. При аварийном выключении и не совпадении метаданных с блоком данных, ext4 считает, что данных этих просто нет. Т.е., по сути, откат транзакции

Все современные ФС размечтаются автоматом с заделом заведомо достаточного смещения

в описанном изначально сценарии мне видится большая вероятность того, что в данных получится смещение с наложением между границами блоков между mysql/ext4/zfs, и отбросится не запись, а таблица

> мы говорим ext4, что у нас данные не по размеру сектора записывать, а блоками по 16кб А как мы это говорим ext4?

Потому, порядок действий такой: 1) Создаём zvol с нужным volblocksize 2) Создаём ФС, для многих из них есть параметры для тюнинга под размер блока данных, чтобы ФС их складировала не разрозненно. Например, в ext4 stride указывает, сколько кластеров должны формировать блок данных. Так как этот тюнинг рассчитан был на корректное размещение данных для raid в stripe, то, желательно, указать stripe-width. В случае с ZFS, он всегда равен stride. 3) Я отключал журналирование данных в ext4, так как у нас эту функцию выполняет zfs. Оставлял только метаданные. 4) Монтирование в виртуальной машине. К сожалению, не записал нигде. Насколько помню: data=ordered,noatime,nobarrier

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

а вот именно на stride я сомневаюсь что так будет работать и не будет потери данных - если нет журнала

Блоки то пишет ZFS. Если запись на завершиться корректно, то ZFS сделает откат - по сути обнулит. Ext4, в свою очередь, сверит этот пустой блок с метаданными, в случае не совпадения, считает блок не записанным, то есть равносильно тому, что данные не поступили

не офтоп это конечно сильно, вам в чат по ext3/4

Всем привет! Думаю не будет считаться оффтопом, в общем вопрос в следующем, на виртуальной машине 1 из дисков не проходит чек файловой системы, фс диска - ext3, размечен в lvm, недавно выяснил, что для отказоустойчивости ext-3/4 могут использоваться барьеры, но на lvm они не поддерживаются. В общем-то вопрос заключается в том, существуют ли какие-то способы восстановить фс на диске с минимальными потерями, либо выборочно достать с него данные (fsck -y /dev/.. очевидно к ним приводит), используя особенности фс? в данном случае это ext3. Пример с барьерами - скорее особенность, как на будущее снизить вероятность поломок фс, что меня тоже интересует

Всем привет! Думаю не будет считаться оффтопом, в общем вопрос в следующем, на виртуальной машине 1 из дисков не проходит чек файловой системы, фс диска - ext3, размечен в lvm, недавно выяснил, что для отказоустойчивости ext-3/4 могут использоваться барьеры, но на lvm они не поддерживаются. В общем-то вопрос заключается в том, существуют ли какие-то способы восстановить фс на диске с минимальными потерями, либо выборочно достать с него данные (fsck -y /dev/.. очевидно к ним приводит), используя особенности фс? в данном случае это ext3. Пример с барьерами - скорее особенность, как на будущее снизить вероятность поломок фс, что меня тоже интересует

Всем привет! Думаю не будет считаться оффтопом, в общем вопрос в следующем, на виртуальной машине 1 из дисков не проходит чек файловой системы, фс диска - ext3, размечен в lvm, недавно выяснил, что для отказоустойчивости ext-3/4 могут использоваться барьеры, но на lvm они не поддерживаются. В общем-то вопрос заключается в том, существуют ли какие-то способы восстановить фс на диске с минимальными потерями, либо выборочно достать с него данные (fsck -y /dev/.. очевидно к ним приводит), используя особенности фс? в данном случае это ext3. Пример с барьерами - скорее особенность, как на будущее снизить вероятность поломок фс, что меня тоже интересует

Всем привет! Думаю не будет считаться оффтопом, в общем вопрос в следующем, на виртуальной машине 1 из дисков не проходит чек файловой системы, фс диска - ext3, размечен в lvm, недавно выяснил, что для отказоустойчивости ext-3/4 могут использоваться барьеры, но на lvm они не поддерживаются. В общем-то вопрос заключается в том, существуют ли какие-то способы восстановить фс на диске с минимальными потерями, либо выборочно достать с него данные (fsck -y /dev/.. очевидно к ним приводит), используя особенности фс? в данном случае это ext3. Пример с барьерами - скорее особенность, как на будущее снизить вероятность поломок фс, что меня тоже интересует

Ответ на второй вопрос - перейти на ZFS) Ответ на первый попробуйте получить в чатах по линуксу или квм, я вам кинул в лс пару ссылок. Либо на старых добрых форумах

Сам сейчас вытягиваю с ext4 поверх LVM (проблема с супер блоками) . Использую testdisk. Уже 5.6 TB вытянул

@neurox

Ссылка была на статью на хабре

придет админ, снимет блокировку. это бот автоматом от новорегов ссылки блочит.

Самое первое сделать с него точную копию Если обычным dd не получается Воспользоваться ddrescue(dd_rescue) Не стоит ни когда работать напрямую со сбойным диском уж тем более бюджетным софтом который пытается выполнить хоть какую либо операцию записи (Самое минимальное это окисление контактной площадки на плате в районе перехода на БМГ, сами головы дохнут, далее уже поверхность) это самое распространённое . Причём окись в 50% точно, так делают Причём без разницы Энтерпрайз или бюджетка один колинкор. Сиги, Тошки почти все подвержены этому в 90% голая медь, очень очень редко покрыта оловом. WG 50% тоже самое, у Фуджиков меньше, HGST практически не встречает такой болячки, там либо луженое либо позолоченный разъём Так что стоит проверить Может это даже облегчит жизнь Звездочку для того чтобы плату скинуть и посмотреть найти не сложно, собственно как и ластик Что касаемо копии, то можно даже на рабочий диск её потом записать и подкинуть вместо оригинала и попробовать в штатном режиме пройти fsck, либо как уже написали выше это testdisk Но этот софт тоже напрямую с носителем работает и тоже пытается там что то писать о чем уже говорил выше Накройняк эту копию можно уже отдать ребятам с DR в дефолтном режиме запись в lvm идёт линейно, значит файло ломаться не должно p.s рекламировать специальное оборудование и ПО не любитель, но на примере того же PC3000 или других подобных девайсов, проблема решалась бы гораздо проще. Причём данный комплекс работает исключительно с копией блоков которые делает на ходу при обращении к какому либо в дальнейшем это место просто пропускается и может читаться с любого блока включая и повторное чтение и пропуск в случае проблем с носителем

Спасибо за развернутый ответ, только диск виртуальный, это диск на ВМ в openstack

Спасибо за развернутый ответ, только диск виртуальный, это диск на ВМ в openstack

Можно его вытащить через опенстак кли

С Openstack не работал из того что я понял устройства разные, значит на уровне хоста всегда можно получить доступ к диску Либо что мешает подкинуть в эту же виртуалку доп диск нужного объёма и той же ливкой сделать копию и все остальное

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

Вот, судя по всему что-то произошло с ним

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

Привет. Есть несколько NVMe samsung 970PRO. ZFS guide, да и здравая логика, готовит что надо форматировать устройства в 4K страницы. Но смотрю в smartctl / nvme-cli, а там только 512байт-ные страницы. Попытка zfs send с raidz2 на данных дисках показывает печальный random read (7MBps с устройства): avg-cpu: %user %nice %system %iowait %steal %idle 0.13 0.00 6.20 0.00 0.00 93.67 Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await dareq-sz f/s f_await aqu-sz %util nvme0n1 12847.00 6658.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.05 100.00 nvme10n1 12983.00 6734.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.05 100.00 nvme1n1 12924.00 6702.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.99 100.00 nvme2n1 12877.00 6683.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.05 100.00 nvme3n1 12885.00 6704.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.07 100.00 nvme4n1 12908.00 6706.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.07 100.00 nvme5n1 12862.00 6676.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.03 100.00 nvme6n1 12812.00 6503.00 0.00 0.00 0.08 0.51 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.06 100.00 nvme7n1 12849.00 6522.50 0.00 0.00 0.08 0.51 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.06 100.00 nvme8n1 12820.00 6665.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.03 100.00 nvme9n1 13093.00 6789.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.08 100.00 Вопрос - чтобы увеличить скорость работы с дисками (random read/write) надо ashift поднять до 12-13 (сейчас он 0) или искать как диски отформатировать под 4K страницы ? Нагрузка - это random read/write (PostgreSQL и прочие)

Привет. Есть несколько NVMe samsung 970PRO. ZFS guide, да и здравая логика, готовит что надо форматировать устройства в 4K страницы. Но смотрю в smartctl / nvme-cli, а там только 512байт-ные страницы. Попытка zfs send с raidz2 на данных дисках показывает печальный random read (7MBps с устройства): avg-cpu: %user %nice %system %iowait %steal %idle 0.13 0.00 6.20 0.00 0.00 93.67 Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await dareq-sz f/s f_await aqu-sz %util nvme0n1 12847.00 6658.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.05 100.00 nvme10n1 12983.00 6734.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.05 100.00 nvme1n1 12924.00 6702.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.99 100.00 nvme2n1 12877.00 6683.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.05 100.00 nvme3n1 12885.00 6704.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.07 100.00 nvme4n1 12908.00 6706.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.07 100.00 nvme5n1 12862.00 6676.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.03 100.00 nvme6n1 12812.00 6503.00 0.00 0.00 0.08 0.51 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.06 100.00 nvme7n1 12849.00 6522.50 0.00 0.00 0.08 0.51 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.06 100.00 nvme8n1 12820.00 6665.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.03 100.00 nvme9n1 13093.00 6789.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.08 100.00 Вопрос - чтобы увеличить скорость работы с дисками (random read/write) надо ashift поднять до 12-13 (сейчас он 0) или искать как диски отформатировать под 4K страницы ? Нагрузка - это random read/write (PostgreSQL и прочие)

Привет. Есть несколько NVMe samsung 970PRO. ZFS guide, да и здравая логика, готовит что надо форматировать устройства в 4K страницы. Но смотрю в smartctl / nvme-cli, а там только 512байт-ные страницы. Попытка zfs send с raidz2 на данных дисках показывает печальный random read (7MBps с устройства): avg-cpu: %user %nice %system %iowait %steal %idle 0.13 0.00 6.20 0.00 0.00 93.67 Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await dareq-sz f/s f_await aqu-sz %util nvme0n1 12847.00 6658.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.05 100.00 nvme10n1 12983.00 6734.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.05 100.00 nvme1n1 12924.00 6702.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.99 100.00 nvme2n1 12877.00 6683.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.05 100.00 nvme3n1 12885.00 6704.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.07 100.00 nvme4n1 12908.00 6706.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.07 100.00 nvme5n1 12862.00 6676.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.03 100.00 nvme6n1 12812.00 6503.00 0.00 0.00 0.08 0.51 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.06 100.00 nvme7n1 12849.00 6522.50 0.00 0.00 0.08 0.51 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.06 100.00 nvme8n1 12820.00 6665.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.03 100.00 nvme9n1 13093.00 6789.50 0.00 0.00 0.08 0.52 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.08 100.00 Вопрос - чтобы увеличить скорость работы с дисками (random read/write) надо ashift поднять до 12-13 (сейчас он 0) или искать как диски отформатировать под 4K страницы ? Нагрузка - это random read/write (PostgreSQL и прочие)

Если они поддерживают

Покажи вывод nvme id-ns /dev/nvme0n1