Александр
Блоки
Sergey
Управление зфс в случае с проксмоксом спрятано в его логике, ручные действия могут скорее повредить, чем помочь
Добрый день всем! Попытался сегодня в ночи восстановить из бекапа lxc контейнер на диск, выдал ту же ошибку что и при попытке переноса диска.
Александр
Sergey
давайте сразу изложу суть сначала
Sergey
пытался перенести lxc на proxmox с zfs на диск, при переносе ругается так
Sergey
TASK ERROR: command 'rsync --stats -X -A --numeric-ids -aH --whole-file --sparse --one-file-system '--bwlimit=0' /var/lib/lxc/111/.copy-volume-2/ /var/lib/lxc/111/.copy-volume-1' failed: exit code 11
Александр
давайте сразу изложу суть сначала
Во. Это прям великая идея. Рассказываешь историю с начала и с максимально подробной диагностикой. "Я тут того а у меня диск не але и на экране тишина" это не очень ценно
Sergey
посоветовали из бекапа востановить на диск
Ivan
TASK ERROR: command 'rsync --stats -X -A --numeric-ids -aH --whole-file --sparse --one-file-system '--bwlimit=0' /var/lib/lxc/111/.copy-volume-2/ /var/lib/lxc/111/.copy-volume-1' failed: exit code 11
это вообще не про zfs. правильней будет решать вопрос в proxmox чате.
Александр
Rsync error code 11 indicates that the disk space is full or the system is unable to detect the external drive. - у тебя там космос слева от устройства есть?
Sergey
recovering backed-up configuration from 'ws2TB:backup/vzdump-lxc-111-2024_02_07-01_52_58.tar'
Formatting '/mnt/pve/nvme0n1/images/111/vm-111-disk-0.raw', fmt=raw size=107374182400
Creating filesystem with 26214400 4k blocks and 6553600 inodes
Filesystem UUID: 25dc6755-c229-48fc-92a5-ae49df668be8
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
restoring 'ws2TB:backup/vzdump-lxc-111-2024_02_07-01_52_58.tar' now..
extracting archive '/mnt/sde1/dump/vzdump-lxc-111-2024_02_07-01_52_58.tar'
tar: ./var/lib/pgpro/1c-13/data/base/49270196/171470785: Cannot write: No space left on device
tar: ./var/lib/pgpro/1c-13/data/base/49270196/171148946: Cannot write: No space left on device
tar: ./var/lib/pgpro/1c-13/data/base/49270196/171274674: Cannot write: No space left on device
Sergey
TASK ERROR: unable to restore CT 111 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar xpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' -C /var/lib/lxc/111/rootfs --skip-old-files --anchored --exclude './dev/*'' failed: exit code 2
Sergey
Обратитесь к своему системному администратору. Если у вас его нет, наймите.
сам пытаюсь разобраться
Sergey
подскажите куда копать?
Александр
сам пытаюсь разобраться
Тут НЕЧЕГО разбираться. Попросите кого-нибудь вслух прочитать диагностику
Александр
Учитесь ДУМАТЬ, а не тыкать во все кнопки подряд
Sergey
на дисках мместа придостаточно
Fedor
в proxmox adminixtration guide написано, как нужно восстанавливать и как искать вводные для такого. это не относится к зфс.
Ivan
на дисках мместа придостаточно
прокс как буфер использует рут емнип. должно быть какое-то место в руте, чтоб вся магия произошла.
Xash
Удали снапшоты лишние и все. Автоматизируй при помощи zfs-prune-snapshot. И натрави ее на нужные цели по времени устаревания. Например 2 недели. Это самое лучшее решение
Sergey
Sergey
прокс как буфер использует рут емнип. должно быть какое-то место в руте, чтоб вся магия произошла.
странность в том, что при восстановлении из бекапа на диск, ошибка есть. на zfs диск норм восстановилось
Vladislav
Удали снапшоты лишние и все. Автоматизируй при помощи zfs-prune-snapshot. И натрави ее на нужные цели по времени устаревания. Например 2 недели. Это самое лучшее решение
Там товарищ игнорирует такие советы, он лучше знает как работать со снапшотами
Xash
Там товарищ игнорирует такие советы, он лучше знает как работать со снапшотами
Ну тогда пусть делает как лучше. Мы практики, нам не шашечки, а ехать.
Xash
George
Xash
Ладно все. Спс за внимание
Сергей
Иван, вы, действительно, прочитайте, что такое снимки файловой системы. Это не резервные копии, не отдельно хранящиеся файлы.
Нет “первого снимка” как сохранённой отдельно резервной копии.
Замораживается состояние ФС на момент снимка. Все занятые блоки будут сохраняться неизменными. Все новые данные будут писаться в пустое место (ZFS copy-on-write делает постоянно, для того же UFS отдельный механизм включается).
“Размер” снэпшота - объём изменённых блоков от создания снимка до ТЕКУЩЕГО состояния диска или до следующего снимка на том же dataset.
central
И?
Сергей
Размер снимка считается как разница между текущим состоянием файловой системы и состоянием БЛОКОВ на момент снимка.
Если блоки были заморожены а предыдущих снимках, то и размер "занятого" места будет относиться к предыдущим снимкам. При их удалении ссылки на блоки посчитаются в следующем снимке.
Почитайте про устройство файловых систем, хотя бы FAT для начала, как вообще устроено хранение на дисках. У нас разговор слепого с глухим, вы концепции вообще не воспринимаете, базовых знаний нет.
Ivan
Vladislav
Vladislav
Я рад, что всё больше людей осознают что это бесммысленно
Сергей
Ваша книжка третьего дня состояла из страниц A, B, C.
Третьего дня вы сохранили состояние. Ссылки на три страницы, физически лежат три страницы.
Второго дня сохранили состояние, ссылки на те же три страницы, но лишних копий не создаётся.
Сегодня вы поменяли страницу B на страницу D, книга состоит из ADC.
Но страница B никуда не делась, если вы хотите почитать позаверашнюю версию - она будет доступна. Размер позавчерашнего снимка - ОДНА страница, вчерашнего - ноль.
Удаляете позавчерашнюю - “занятая страница” будет посчитана во вчерашнем снимке. Но опять одна - только та, что отличается от сегодняшней версии.
Учите матчасть. Ну невозможно в десятке сообщений вменяемого размера передать пару глав учебника.
Александр
Это вы либо что-то не так поняли, либо у вас какой-нибудь спул инкрементально снапшотится или /tmp
Aleks
Видимо в этой ситуации мнение о паре изменившихся гигабайт основывается на размере занятого места?
Aleks
100гб удалили -> 102гб записали -> инкремент должен весить 2гб. Я всё правильно понимаю?
Станислав
Artem
Снапшот не весит почти ничего, так как содержит лишь ссылки на данные, адреса блоков. Весят данные, их размер Вы принимаете за размер снапшота. Хотите освободить место - избавляйтесь от данных, не от снапшотов.
Aleks
Снапшот не весит почти ничего, так как содержит лишь ссылки на данные, адреса блоков. Весят данные, их размер Вы принимаете за размер снапшота. Хотите освободить место - избавляйтесь от данных, не от снапшотов.
сначала от данных, потом от снапшотов в которых содержатся данные о них
Free
Имеется два сервера с одиночными zfs дисками/пулами.
На одном есть пул, который после перезугрузки не хотел импортироваться, просил импорт с ключом -F (с потерей нескольких секунд записи данных). На другом - вообще нормально загружались все пулы, статус ONLINE, ни одной "известной ошибки".
Перезугрузку приходилось делать выключением питания (просто shutdown или reboot через некоторое время зависает с мертвой картинкой логотипа десктопной убунты).
После перезагрузки через некоторое время работы серверов на обоих любая команда zpool (например, status) безнадежно зависает.
Поиск по zpool hangs выдает рекомендации вроде импорта пула в режиме read only без монтирования и проведение ресилвенга - но ведь для одиночного диска ресилвенг вряд ли приведет к результату - для этого избыточность нужна?
Какие способы хотя бы разобраться, что там с пулом (ами) происходит? 🤔
Vladislav
Во-первых, повисает он скорее всего на zpool import
Vladislav
Которая выполняется при запуске
Vladislav
Дальше - смотри логи, что валятся в dmesg и journalctl
Vladislav
Во-первых, повисает он скорее всего на zpool import
Провались в загрузочный шел, гугл в помощь как это делать на десктопной убунту
Free
Во-первых, повисает он скорее всего на zpool import
На одном из дисков действительно импорт был совсем проблемный, с зависанием. Этот диск сейчас отключил. Остальные диски импортируются, после импорта показывают статус ONLINE без ошибок. Но после работы с данными этих дисков что-то происходит. Комьпютер НЕ ПОДВЕШИВАЕТСЯ, только команда zpool перестает работать (иногда после этого и zfs тоже подвисает), и данные пула(ов) перестают быть доступными
Free
Дальше - смотри логи, что валятся в dmesg и journalctl
Смотрел, мало информативно.
Например,
INFO: task zpool:102439 blocked for more than 362 seconds.
[ 1330.298545] Tainted: P O 6.2.0-39-generic #40~22.04.1-Ubuntu
[ 1330.298546] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1088.635800] INFO: task txg_sync:104357 blocked for more than 120 seconds.
[ 1088.635802] Tainted: P O 6.2.0-39-generic #40~22.04.1-Ubuntu
[ 1088.635803] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Free
Диски новенькие Exos X20 и X18
Free
Данные на них переносились send-receive совсем недавно. На некоторых есть с "больного" пула - там могли быть какие-то проблемы c ошибками, я их в первую очередь изолировал.
Сейчас проблемы возникают и на тех, куда переносил с совершенно здорового пула, без отключения режима контроля ошибок send.
Алексей
Mikhail
цеф-шайтан детектед
Free
Напомни там есть l2arc?
🤷♂️ Не знаю, я с настройками l2arc ничего не делал.
На двух других серверах те же диски с теми же настройками пашут без проблем.
Xash
Zfs - были ранее огромные проблемы с ним. Отваливались диски.
Сейчас перепроверил все че можно, переключил че можно в hba и отключил хардвар кеши.
Пока 4 мес полет нормальный на тех серверах.
Free
Во-первых, повисает он скорее всего на zpool import
А вот сегодня уже на стадии импорта одного из пулов zpool (а вместе с ним и zfs) стал зависать.
При этом уже импортированные пулы работают нормально.
И что в таких случаях рекомендуется делать 🤔?
central
Free
А вот сегодня уже на стадии импорта одного из пулов zpool (а вместе с ним и zfs) стал зависать.
При этом уже импортированные пулы работают нормально.
И что в таких случаях рекомендуется делать 🤔?
Импортировал в readonly.
Среди ошибок в файлах выданы ошибки в метаданных, вида
errors: Permanent errors have been detected in the following files:
s28/374:<0x0>
...
s28/374:<0x5a8a>
...
Это лечится?
Или только пофайловым переносом того, что не повреждено?
Aleks
Free
А проверяли её после того, как проблемы начались?
Попробую при следующей перезагрузке
memtester или что-то порекомендуете?
Станислав
Попробую при следующей перезагрузке
memtester или что-то порекомендуете?
Его достаточно. Но долго может проверять, если сразу ошибки не полетят
Fedor
версию zfs лучше свежую, 2.2.x или 2.1.x, в зависимости о того что есть
Shaker
Sebastian
ща 6 остался
central
/report
Group Butler
Vladislav
Мне всегда нравится, что kmod никогда не совпадает с zfs
Станислав
Мне всегда нравится, что kmod никогда не совпадает с zfs
У меня почему-то всегда совпадает