я под debian12 скомпилировал zfs 2.3.0 пару дней назад, погонял немного, все норм... наверное, да. ядро бы стабильное и дистрибутив проверенный.

в sid уже есть zfs 2.3.0. можно было не компилировать.

не подключайте репозиторий sid, без четкого представления! можно систему сломать.

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

да говорит-то говорит, просто смущает пустой список файлов "in question" в конце, поэтому и затрудняюсь делать выводы

да говорит-то говорит, просто смущает пустой список файлов "in question" в конце, поэтому и затрудняюсь делать выводы если бы список поврежденных файлов был бы не пустым - то можно было бы просто удалить поврежденный файл и восстановить его из резервной копии и после этого - количество ошибок было бы равно нулю. 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 а так как поврежденных файлов нет в списке - значит повреждения файловой системы на диске более серьезные и более глубокие и просто удалением какого-то одного файла и его восстановлением из бэкапа проблему решить не получится, и придется пересоздавать весь zfs pool. и, кстати, это как раз и очень похоже на аппаратные проблемы с сервером, когда такое серьезное повреждение файловой системы происходит. потому что, как правило, программные ошибки в коде OpenZFS приводят только к повреждению каких-то конкретных файлов, с которыми шла работа, а не более глубокому повреждению всей файловой системы, как в этом случае произошло.

А вот есть у меня второй пул, тоже зеркало, диски там другие, на 2тб. Туда синкоидом инкрементально раз в день отправляются нужные мне датасеты, на которые я распределил квоты, чтобы они гарантированно влезали в бэкапный пул. После теоретического устранения аппаратных проблем и уничтожения/пересоздания основного 4тб пула, насколько сомнительно будет просто сэндом отправить обратно все датасеты, например откатившись до одного из снэпшотов, сделанных до инцидента, и быть уверенным в целостности данных? Второй пул не содержит ошибок на данный момент. Или стоит подойти как-то иначе к этому вопросу?

В той ситуации как сейчас - я бы не стал использовать zfs send | zfs receive для копирования данных между двумя zfs pool. Почему? Даже если будут обнаружены и устранены все аппаратные проблемы с сервером - файловая система уже повреждена и это могло уехать и на второй zfs pool по репликации - поэтому я бы не стал так сильно рисковать и использовал бы какое-то другое средство для backup / restore данных и переноса их с одной файловой системы на другую файловую систему. Копирование данных через zfs send | zfs receive удобно тем, что надо мало ресурсов, по сравнению с другими средствами копирования, особенно если используется инкрементальный режим и пересылаются только отличия между двумя снапшотами. Но в данной ситуации - нет особого смысла экономить циклы процессора и пропускную способность сети, и поэтому имеет смысл использовать более надежное, хоть и более ресурсоемкое решение для копирования и переноса данных между двумя файловыми системами. В том случае, когда использовать только обычное POSIX API для работы с файлами - тогда наименьшая вероятность и возможность копирования ошибок с одного zfs pool на другой zfs pool. Даже самый простой вариант копирования данных, через rsync с моей точки зрения, будет лучше в данной ситуации, чем использование zfs send | zfs receive

Невозможно бекапить каждую минуту. Тем более виртуалки. Их погасить надо. А у нас за день столько работы может пролететь в базах.

What the fuck hell?

Давай без такой лексики

Невозможно бекапить каждую минуту. Тем более виртуалки. Их погасить надо. А у нас за день столько работы может пролететь в базах.

Если проект ответственный, бекапить надо не вм, а сервис. Через бекап вм консистентный бекап сделать сложно

Если проект ответственный, бекапить надо не вм, а сервис. Через бекап вм консистентный бекап сделать сложно

до чекпоинта должно быть консистентно, если методом снапшота бэкапить.

до чекпоинта должно быть консистентно, если методом снапшота бэкапить.

делаете фриз, снимаете снэпшот(ы), бэкапите состояние памяти, размораживаете виртуалку, бэкапите снэпшот. 3-5 секунд даунтайма.

атомарно виртуалкам фриз не сделать

а в чем проблема?

например?

делаете фриз, снимаете снэпшот(ы), бэкапите состояние памяти, размораживаете виртуалку, бэкапите снэпшот. 3-5 секунд даунтайма.

один хрен тот же pitr на снапах не организуешь

Для этого есть интеграция с БД. Почитай про любые энтерпрайз решения СРК

В частности - с ZFS снапшотами придётся присобачить ещё костыли, чтобы все участники процесса - СРК, Гипер, гостевая ОС, ZFS синхронно выполняли свои операции

оверижениринг

Подскажи, как посмотреть % удачных попаданий в arc?

Добрый вечер. При установке proxmox, не углядел что стоит не весь объём диска а 20 гб,Как вместо раздела отдать zfs весь диск, autoexpand не дал никакого результата.

А есть что то с GUI менеджер разделов для Zfs ?

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

штош...

нет, zfs так не расширяется... Что Вы можете сделать: Создать mirror пул, подключив новый диск или раздел нового диска ТОЧНО ТАКОГО ЖЕ размера как третий раздел от конца второго раздела до конца диска. Дождаться, когда данные синхронизируются. Затем вывести первоначальный диск с разделом. Удалить раздел на этом диске. Ввести его в пул как mirror Дождаться, когда данные синхронизируются. Затем удалить из пула вспомогательный диск. Затем сделать autoexpand (я надеюсь знаете как это делать)

А потом?

нет, zfs так не расширяется... Что Вы можете сделать: Создать mirror пул, подключив новый диск или раздел нового диска ТОЧНО ТАКОГО ЖЕ размера как третий раздел от конца второго раздела до конца диска. Дождаться, когда данные синхронизируются. Затем вывести первоначальный диск с разделом. Удалить раздел на этом диске. Ввести его в пул как mirror Дождаться, когда данные синхронизируются. Затем удалить из пула вспомогательный диск. Затем сделать autoexpand (я надеюсь знаете как это делать)

нет, zfs так не расширяется... Что Вы можете сделать: Создать mirror пул, подключив новый диск или раздел нового диска ТОЧНО ТАКОГО ЖЕ размера как третий раздел от конца второго раздела до конца диска. Дождаться, когда данные синхронизируются. Затем вывести первоначальный диск с разделом. Удалить раздел на этом диске. Ввести его в пул как mirror Дождаться, когда данные синхронизируются. Затем удалить из пула вспомогательный диск. Затем сделать autoexpand (я надеюсь знаете как это делать)

pool: main state: ONLINE config: NAME STATE READ WRITE CKSUM main ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ata-EX295278RUS2TB_AA2312180003 ONLINE 0 0 0 ata-EX295278RUS2TB_AA2312180024 ONLINE 0 0 0 errors: No known data errors pool: rpool state: ONLINE config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 ata-TS256GSSD470K_H665230175-part3 ONLINE 0 0 0 errors: No known data errors

По описанию проблема как раз в том, что был создан раздел на 20ГБ для ZFS из ГУИ прокса

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

Я не знаток прокса, но он вполне возможно создал раздел на диске, который затем уже отдал ZFS.

пошагово описать?

Disk /dev/sdi: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: EX295278RUS 2TB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 5593EC0E-FB5E-044D-BA39-F52A101782DF Device Start End Sectors Size Type /dev/sdi1 2048 3907012607 3907010560 1.8T Solaris /usr & Apple ZFS /dev/sdi9 3907012608 3907028991 16384 8M Solaris reserved 1 Disk /dev/sdj: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: EX295278RUS 2TB Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 4068EB9A-5A8E-174B-AB98-BF2E8F6E07B2 Device Start End Sectors Size Type /dev/sdj1 2048 3907012607 3907010560 1.8T Solaris /usr & Apple ZFS /dev/sdj9 3907012608 3907028991 16384 8M Solaris reserved 1 Disk /dev/sdk: 238.47 GiB, 256060514304 bytes, 500118192 sectors Disk model: TS256GSSD470K Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: C2EC7A85-0F5C-41C5-BF60-2967D05CDA70 Disk /dev/sdl: 238.47 GiB, 256060514304 bytes, 500118192 sectors Disk model: TS256GSSD470K Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BDAE3C2A-AE90-495E-A5F5-D80F8805F31F Device Start End Sectors Size Type /dev/sdl1 34 2047 2014 1007K BIOS boot /dev/sdl2 2048 2099199 2097152 1G EFI System /dev/sdl3 2099200 28121088 26021889 12.4G Solaris /usr & Apple ZFS Disk /dev/zd0: 32 GiB, 34359738368 bytes, 67108864 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 16384 bytes I/O size (minimum/optimal): 16384 bytes / 16384 bytes Disklabel type: gpt Disk identifier: 36E16A4D-FA18-4A1E-837D-1BEA1EE27E4B Device Start End Sectors Size Type /dev/zd0p1 4096 6143 2048 1M BIOS boot /dev/zd0p2 6144 1054719 1048576 512M EFI System /dev/zd0p3 1054720 67108830 66054111 31.5G Solaris /usr & Apple ZFS Disk /dev/zd16: 80 GiB, 85899345920 bytes, 167772160 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 16384 bytes I/O size (minimum/optimal): 16384 bytes / 16384 bytes Disklabel type: gpt Disk identifier: 08D52EC4-DC93-4D9A-904C-BA5B98A8F93F Device Start End Sectors Size Type /dev/zd16p1 2048 167770111 167768064 80G Solaris /usr & Apple ZFS

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

Итак, fdisk /dev/sdl