Привет! Кто-нибудь сталкивался с такой проблемой? Я использую Ubuntu 22.04 с ZFS 2.1.5. На этой системе есть sparse ZVOL на несколько терабайт, который я подключаю к винде через iSCSI. В определенный момент мы заметили, что данные начали пропадать. Когда я запускаю chkdsk, он находит ошибки, исправляет их и на какое-то время все приходит в норму. Но через некоторое время данные снова повреждаются. Мы делаем снапшоты этого ZVOL-тома для резервного копирования. В момент создания снимка, мы отключаем диск от Windows-системы. Можно как то у zfs узнать консистентность датасета?

Хорошо, ему и сата ссд будет хватать, поэтому особо не смотри на скорость, там всё равно не последовательное чтение

Все диски живые.

пул на хардах после определённого кол-ва дисков будто пошустрее саташника будет

на реддите под катом такое: Apparently block cloning just aggrevates the issue... Какжется как раз мой случай

Как думаете, может влиять различие размера блока? На волюме volblocksize 16K. На ntfs 8k. То что читал, пишут. что самое плохое что может быть в такой ситуации это write amplification.

Block cloning это просто reflink

Да, я видел пост, нет, это касается копирования внутри самого zfs как ФС, не когда это zvol наружу как я понял @gmelikov, баг с корраптом же только на ФС и zvol никак не затронут был?

[Unit] Description=Continuous replication of media storage After=network.target [Service] ExecStart=/usr/sbin/syncoid root@0.0.0.0:HDD/media HDD/media --create-bookmark Restart=always RestartSec=10000ms StartLimitInterval=0 [Install] WantedBy=multi-user.target

@neurox как у этого бота запрет снимается ?

Привет! Удаляется из рестрикта в телеге, больше ничего не нужно. А кого забанило?

sparse тогда тоже вряд ли влияет.

Хотя, сейчас уточню

Ок. Попрбуем

Полтора доллара за хранение 1тб за месяц. Учитываются так назвваемые терабайто-часы хранятся. Еще немного доплачивают за трафик но там копейки

Электричества не больше наматывается, чем выходит оплаты?)

Электричества не больше наматывается, чем выходит оплаты?)

Вот mpstat двух ядер. Нормального и с проблемой. Но реальной нагрузки нет.

Приветствую, нужна помощь. Переустановил на сервере debian с 11 на 12 и столкнулся с проблемой. Посреди ночи примерно раз в 2-3 дня без каких либо видимых причин одно ядро на процессоре застревает в 100% iowait. Дисковой нагрузки нет, сами диски целые, в dmesg пусто. Из подозреваемых либо ядро, либо модуль zfs. Изначально и то и другое ставил из backports - ядро 6.5.10 и zfs 2.2.2. На багтрекере пишут, что с ядрами 6.4 была регрессия, которую пофиксили в 6.4.8 и 6.5.0-rc4 (https://bugzilla.kernel.org/show_bug.cgi?id=217699). Однако у меня проблема возникает и с более новым ядром и после возврата на штатное 6.1. В связи с этим вопрос, может не ядро виновато? Кто-нибудь сталкивался с подобным в zfs 2.2.2? Куда ещё копать?

А что за проц? Случаем не ryzen?

autotrim включен?

По syncoid. Очень мощно грузит подсистему дисков. Не включайте в момент работы.

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

Привет! Кто-нибудь сталкивался с такой проблемой? Я использую Ubuntu 22.04 с ZFS 2.1.5. На этой системе есть sparse ZVOL на несколько терабайт, который я подключаю к винде через iSCSI. В определенный момент мы заметили, что данные начали пропадать. Когда я запускаю chkdsk, он находит ошибки, исправляет их и на какое-то время все приходит в норму. Но через некоторое время данные снова повреждаются. Мы делаем снапшоты этого ZVOL-тома для резервного копирования. В момент создания снимка, мы отключаем диск от Windows-системы. Можно как то у zfs узнать консистентность датасета?

По тому что новые снимки нужно пересылать в инкрементальном режиме вручную или использовать syncoid (команда из пакета sanoid) для их автоматической репликации. Ещё надо будет что-то придумать, чтобы удалять уже пересланные снимки. Это очень дешевый и черезвычайно быстрый медод репликации, можно производить репликацию и через ssh-соединение, что работает в syncoid из ксробки

Если снимков нет на стороне источников, а в текущем снапшоте изменились данные - засинкает разницу?

Разве в снапшоте может что-то измениться?😳

Если снимков нет на стороне источников, а в текущем снапшоте изменились данные - засинкает разницу?

Если снимков нет на стороне источников, а в текущем снапшоте изменились данные - засинкает разницу?

Если снимков нет на стороне источников, а в текущем снапшоте изменились данные - засинкает разницу?

По тому что новые снимки нужно пересылать в инкрементальном режиме вручную или использовать syncoid (команда из пакета sanoid) для их автоматической репликации. Ещё надо будет что-то придумать, чтобы удалять уже пересланные снимки. Это очень дешевый и черезвычайно быстрый медод репликации, можно производить репликацию и через ssh-соединение, что работает в syncoid из ксробки

Если снимков нет на стороне источников, а в текущем снапшоте изменились данные - засинкает разницу?

Итог - в сравнении с rsync быстрее процентов на 15-20. Чудес нет. Но оно работает.

Инкрементная передача снимков возможна только в одном случае - на источнике и приёмнике имеется снимок, относительно которого передаётся разница. Т.е. вы можете создать снимок 1, передать его. Создать снимок 2, передать его инкрементно относительно 1. Удалить снимок 1 (везде, или только в одном из местоположений) Создать снимок 3 и передать его относительно 2. Как только у источника и получателя пропадает общий снимок, инкрементная передача невозможна.

А снимок надо удалять? Он же сам не удалится.

А кто как произносит ZFS? ЗедФС Или ЗФС

А кто как произносит ZFS? ЗедФС Или ЗФС

А кто как произносит ZFS? ЗедФС Или ЗФС

А кто как произносит ZFS? ЗедФС Или ЗФС

есть еще zxfer, например... а для автоматизации создания снимков - zfstools. правда на линь их нужно немного подпиливать, но там не страшно. И у меня, вроде были линёвые форки, могу скинуть.

Инкрементная передача снимков возможна только в одном случае - на источнике и приёмнике имеется снимок, относительно которого передаётся разница. Т.е. вы можете создать снимок 1, передать его. Создать снимок 2, передать его инкрементно относительно 1. Удалить снимок 1 (везде, или только в одном из местоположений) Создать снимок 3 и передать его относительно 2. Как только у источника и получателя пропадает общий снимок, инкрементная передача невозможна.

А снимок надо удалять? Он же сам не удалится.

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

Да, надо удалять, или конвертировать в закладки.

Приимущества передачи снимков ещё и в их консистентности. Работающую базу данных нельзя rsync-ом во время работы бекапить, а снимками можно.

Зачем?

Не всякую БД

Нет

По тому, что из-за ниличия снимка, растёт занимаемое место при записи в пул. Подумайте о том, что снимок блокирует данные на которве он ссылается. Если вы удалили файл после создания снимка, место занимаемое файлом не высвободится пока вы не удалите все снимки, где этот файл существует. Если вы перезаписали часть файла после создания снимка, эта новая информация займёт свободное место и оно не освободится, пока существуют снимки блокирующие её удаление перезаписанной информации. Снимки это как машина времени.

Буду благодарен. У меня жту функцию выполняют самописные bash-скрипты. Кстати, есть скрипт, который проверчет что всё впорядке с бекапом. Он создаёт sqlite-базу данных и записывает в неё: - информацию о хранящихся на backup-сервере снимках: их именах и giud; - подключается к каждому, указанному в конфигурации гипервизору proxmox, и записывсет в несколько таблиц в базе данных информацию о найденных виртуальных машинах, их zvol, снимках на этих zvol и отношениях между ними. Затем скрипт выполняет sql-запрос, кстати написанный chat-gpt :-) и вычисляет zvol и виртуальные машины у которых не найдено актуальных резервных копий и выводит предлагаемые правки конфигрурационных файлов к скрипту создания снимков и скрипту передачи снимков. Я понемногу допиливаю этот скрипт. Ближайщее время, план рую бобавить функционал сбора и сопоставления информации о smb- и nfs-шарах, хранящихся в zfs.

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

А зачем? https://github.com/psy0rz/zfs_autobackup

Сами по себе бд на zfs не портятся, тут все так. Использоваие снапшотов для клонирования бд, в частности oracle, вот тут появляются нюансы. Я тоже давно использую zfs

На нагруженных по io системах, сразу после создания снимка нсчинается рост занятого места. Представьте что это относительна не большая и дорогая ssd с базой данных, какой-нибудь optane. По этому, лучше всего как можно быстрее передать снимок к месту его хоанения и конвертировать переданный снимок в закладку, что высвободит всё занятое место.

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

Поправочка: разницу можно отправлять не только между двумя снимками, но и мнжду снимком и закладкой (zfs bookmark). В отличие от zfs-снимков, zfs-bookmark не занимают места. Syncoid может после успешной передачи конвертировать переданный снимок в закладку, кроме того он автоматически продолжает прерванные передачи, что очень удобно.

Кто то использовал WD Purpure под RAIDZ? А то выше говорили что они ошибки пропускают, но ведь там стриминг только при использовании соответствующих ATA команд, а по умолчанию обычный диск с TLER и не более того.