LINUX.ORG.RU
решено ФорумAdmin

Ищутся ГУРУ zfs. Поломал zfs, осваиваю насколько оно починябельное.

 ,


1

3

В общем поломал благодаря USB 3. Переставил местами 2 адаптера, у них были кабели разной длины, и вот один из них не смог нормально отработать с кабелем от другого. Делал банальный рсинк. В нгазначении получил что то типа:

  pool: T4T3S
 state: DEGRADED
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
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
  scan: scrub repaired 464K in 06:48:46 with 8 errors on Sun Feb  9 07:12:55 202
5
config:

        NAME         STATE     READ WRITE CKSUM
        T4T3S        DEGRADED     0     0     0
          T4T3STORE  DEGRADED     0     0 41.7K  too many errors

errors: Permanent errors have been detected in the following files:

        T4T3S/:Backup:<0x50700>
        /zfs/=T4T3S/:Backup/Hosts/HGST-750/Backup-241127=330(172)Gb/p8-zz750/zz-s64root/usr/share/doc/gcc-6-base/libstdc++/user/a09413.html


Естественно битые файлы - пустые.
Подумал что для начала надо их удалить.
Сделал список из файлов и произвёл над ними gzip -m
Всё как бы замечательно, но вот конструкции типа:
T4T3S/:Backup:<0x50700> - остались как ошибочные, при этом другими средствами они не видны.
Как бы удалить эти конструкции?
И что надо сделать после их удаления?
scrub?
а потом убрать флаг ошибки? Или как это делается?
Теоретически конечно я уже сделал рсинк на другой винт и можно этот переразметить и рсинкнут назад, но хочется освоить другой метод, да и рсинк 1.94T упакованных до 1.84T взад - опять будет идти 40+ часов. Можно конечно отрубить упаковку (Выигрыш всего 100G). Но всё же...

(250225-2300)P.S. Последовательность действий:
1. zpool status -v|tee errors.log
2. С помощью гугла нашел команды для преобразования полученного списка в список файлов с ошибками (errors.lst). По ходу удалив строки вида: T4T3S/:Backup:<0x2e2802> - ибо они не являются файлами
3. Если не путаю (память шалит) #zip -m badfiles.zip -@ <errors.lst и все битые файлы были упакованы в архив и удалены на разделе.
4. zpool status <POOL> -v|tee errors.log - Дал только строки вида: T4T3S/:Backup:<0x50700>
5. zpool scrub <POOL> - через 6 часов - 0 ошибок.
6. zpool clear <POOL>
Всё:
# zpool status T4T3S
  pool: T4T3S
 state: ONLINE
  scan: scrub repaired 16K in 06:01:52 with 0 errors on Tue Feb 25 21:27:33 2025
config:

	NAME         STATE     READ WRITE CKSUM
	T4T3S        ONLINE       0     0     0
	  T4T3STORE  ONLINE       0     0     0

errors: No known data errors


В файле badfiles.zip - список файлов которые надо восстановить из других источников.

Спасибо unC0Rr и undef которые советовали по сути, а не «учили» меня «как надо».

Отмечаю тред решенным!

★★★

Последнее исправление: cetjs2 (всего исправлений: 4)
Ответ на: комментарий от pekmop1024

ZFS тебе для чего? Если «слышал, что это круто», то тебе оно не нужно:

Я zfs использую уже более 10 лет. Оно и правда круто. Работает, «держит» упаковку. Запоминает пути на которые её смонтировали. Удобно извращаться, сделать пул а в нём всяких POOL/var-spool, POOL/var-log, POOL/home и затем смонтировать их в /var/spool, /var/log, /home и всё что угодно «ТОЛСТОЕ» можно вынести на zfs - не вынося... Свободное место будет одно и то же на всех.

Грохнуть корраптнутое, отформатировать в ext4, рсинкнуть на место. Забыть как про страшный сон.

Я просил помочь с zfs, а не рекомендовать другое.
И БЕСИТ меня ext4 своими: ... (забыл уже как выглядят строки о похерянии забытых кластеров). Я уже использовал и jfs, и xfs, и btrfs - но прижилась zfs.

Бесят эти sda,sdb,sdc,sdd,sde,sdf<1234566789> на zfs я не заморачиваюсь. zpool import T4T3S и всё - она встаёт про прописанным у неё точкам монтирования. Хотя конечно косяк, когда одинаковый mountpoint=/opt у POOL/opt в разных пулах...

Чтобы понять тяжесть ситуации - мой lsblk:

sda                                             8:0    0 119,2G  0 disk  
├─sda1                                          8:1    0     1M  0 part  
├─sda2                                          8:2    0   110G  0 part  
│ ├─0F--BMAX--SSD-swap                        254:0    0   7,4G  0 lvm   [SWAP]
│ └─0F--BMAX--SSD-root                        254:1    0 102,5G  0 lvm   /
└─sda3                                          8:3    0   9,2G  0 part  
sdb                                             8:16   0   1,8T  0 disk  
├─sdb1                                          8:17   0     1M  0 part  
└─sdb2                                          8:18   0   1,8T  0 part  
sdc                                             8:32   0 931,5G  0 disk  
├─sdc1                                          8:33   0  37,3G  0 part  /media/n0mad/TS1TD10X32root
├─sdc2                                          8:34   0   3,7G  0 part  
├─sdc3                                          8:35   0     1K  0 part  
└─sdc5                                          8:37   0 890,5G  0 part  /media/n0mad/WalkerData
sdd                                             8:48   0   3,6T  0 disk  
├─sdd1                                          8:49   0     8M  0 part  
└─sdd2                                          8:50   0   3,6T  0 part  
sde                                             8:64   0   3,6T  0 disk  
├─sde1                                          8:65   0     1M  0 part  
└─sde2                                          8:66   0   3,6T  0 part  
sdf                                             8:80   0 465,8G  0 disk  
├─sdf1                                          8:81   0    40G  0 part  
├─sdf2                                          8:82   0     1G  0 part  
├─sdf3                                          8:83   0     1K  0 part  
├─sdf5                                          8:85   0  24,3G  0 part  /media/n0mad/ST500x1.Free
└─sdf6                                          8:86   0 400,5G  0 part  
  └─luks-aa6f6788-ff14-447d-a936-b69786f28a6b 254:2    0 400,5G  0 crypt /media/n0mad/ST500x1.Crypted
mmcblk0                                       179:0    0 116,5G  0 disk  
├─mmcblk0p1                                   179:1    0   100M  0 part  /boot/efi
├─mmcblk0p2                                   179:2    0    16M  0 part  
├─mmcblk0p3                                   179:3    0   780M  0 part  
├─mmcblk0p4                                   179:4    0   9,4G  0 part  
└─mmcblk0p5                                   179:5    0 106,2G  0 part  
mmcblk0boot0                                  179:256  0     4M  1 disk  
mmcblk0boot1                                  179:512  0     4M  1 disk  

n0mad ★★★
() автор топика
Ответ на: комментарий от anonymous

https://openzfs.github.io/openzfs-docs/man/master/8/zdb.8.html

Если не найдётся ГУРУ - придётся. Но для применения его команд надо хорошо знать архитектуру ФС.

Если не готов к такому, то ответ у тебя в ОП:

restore the entire pool from backup

Я в общем то нашел бэкап, хотя думал что грохнул. Но раз случился такой инцидент - надо освоить алгоритм починки. Сейчас есть Бэкапный винт. Я рсинкнул на него и могу теперь с исходником делать что хочу. Но в будущем редко когда будет «свободный» 4Т диск для исправления подобных ситуаций с помощью реформата и перезаливки.

n0mad ★★★
() автор топика
Ответ на: комментарий от n0mad

У меня lsblk выглядит сложнее и объемнее, но никакой боли от этого не испытываю. Может быть потому, что ничего ручками менеджить никогда не пытаюсь.

А вот зачем нужна фс, которая от операции чтения крашится - вопрос, вопрос…

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

А вот зачем нужна фс, которая от операции чтения крашится - вопрос, вопрос…

Потому что в ней предусмотрен даже такой ньюанс. Крайний раз я монтировал раздел с флагом ридонли и сливал данные.

n0mad ★★★
() автор топика
Ответ на: комментарий от anonymous

zfs usb

Так держать!

Чего полезного ты привнёс этим акцентом?
При ошибках в системе хранения - любая ФС потеряет данные, и любая может серьёзно упасть...
Нужно просто найти стабильный набор железа.
Сейчас я «ютюсь» на BMAX B1 PRO - погугли. Тут вариант или USB3, но конечно можно разориться на m.2 ssd - Какие они бывают самые толстые? А USB3 Дисков тут 5, 4+4+2+1+0.5=11.5T конечно исторически - не все zfs.

Для начала, пока жду ГУРУ - тупо сделаю scrub на пуле.

n0mad ★★★
() автор топика
Ответ на: комментарий от undef

Очистить ошибки, удалить/восстановить битые файлы и сделать scrub, возможно 2 раза. Обычно этого хватает.

Вопрос в том как удалить:

errors: Permanent errors have been detected in the following files:

        T4T3S/:Backup:<0x50700>
        T4T3S/:Backup:<0x2c0700>
        T4T3S/:Backup:<0x1a3500>
        T4T3S/:Backup:<0x2b3800>

n0mad ★★★
() автор топика
Ответ на: комментарий от undef

Такие ошибки чистил двухкратным скрабом. Иногда прокатывало zpool scrub pool; zpool scrub -s pool; zpool scrub pool

Не, останавливать не буду. В статусе он рассчитал что через 5 часов отработает. Поссмотрим результат.

n0mad ★★★
() автор топика

я не считаю себя спецом в ZFS, но прошу рассказать о задачах, что тебе надо в пул добавлять USB?

Как бы удалить эти конструкции? И что надо сделать после их удаления?

RTFM! И срочно.

Теоретически конечно я уже сделал рсинк

rsync и ZFS…

Eulenspiegel
()
Ответ на: комментарий от Eulenspiegel

тебе надо в пул добавлять USB

BMAX B1 PRO - это двухядерный атомный селерон N4000 и 8 гигов оперативы, если ТС туда ничего не накинул. У этой коробочки выбор интерфесов подключения носителей весьма небогатый.

Вопрос целесообразности сего решения поднимать не буду. Мне интересно, чем всё разрешится.

Radjah ★★★★★
()
Ответ на: комментарий от Eulenspiegel

я не считаю себя спецом в ZFS, но прошу рассказать о задачах, что тебе надо в пул добавлять USB?

«БЮДЖЕТ» :) МОБИЛЬНОСТЬ! и сейчас будет многа букаф!
Я не могу себе позволить комп за 100+к, а задёшево не купить что то приемлемое.
Есть древний системник, там сейчас Зеркало из 2*4Т и отдельный 3Т, но лопает он 250+ ватт, хотя и не быстрый. А 250Ватт это Более 700р в месяц.

Можно наверное подобрать и собрать современный «зелёный» комп, но у меня нет квалификации на подборку нужных комплектующих, а нынешние продаваны - впарят «что покруче».

В общем то и началось всё «ТУТ». Когда народ меня «опускал» с моим древним P4. Я купил BMAX B1 Pro, за 8000р. Оно лопает 15 Ватт, при этом быстрее того древнего P4 и памяти 8. К нему начал подбирать «комплект». Теперь это 120Gb M.2 SSD на которую я поставил Debian, USB3 Хаб с БП и 5 Винтов... Всё работает, но есть ньюансы. Как оказалось - один из 2 USB адаптеров - не выносит смену USB3 кабеля.

Как бы удалить эти конструкции? И что надо сделать после их удаления?

RTFM! И срочно.

Какой именно? Есть пруфлинк?

Теоретически конечно я уже сделал рсинк

rsync и ZFS…

Это типа такой сарказм? Надо было send/receive? Но я пока не совсем понимаю механизма работы этого механизма. И опять же, на исходном томе ОШИБКИ! Что с ними будет при send/receive? Они не синкнутся?

n0mad ★★★
() автор топика
Ответ на: комментарий от mord0d

Я не понимаю смысла использования сложных программных дисковых систем/массивов без надежной «железной» основы, включая бесперебойное питание. Развалится, не соберешь из-за сложности.

anonymous
()
Ответ на: комментарий от mord0d

Ну и на будущее: никогда не используй ZFS по USB.

Увы! Пока другого решения нет. И не переливать же все данные с десктопа по 100Мбит сети? А все штатные 4 SATA там уже заняты. SSD+HDD+HDD+HDD. А USB3 вполне тянет >150Mb/s

n0mad ★★★
() автор топика
Ответ на: комментарий от n0mad

А USB3 вполне тянет >150Mb/s

USB не обеспечивает стабильное питание, потому диски могут отваливаться на какое-то время. На "обычных" файловых системах ты этого даже не заметишь, ZFS побьётся, а Btrfs вообще рассыпется и превратится в тыкву.

mord0d ★★★★★
()
Ответ на: комментарий от anonymous

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

Смысл - ИСПОЛЬЗОВАТЬ! Развалиться с таким же успехом может и простая система! Надёжной и мало потеребляющей конструкции я увы пока не вижу.

Развалится, не соберешь из-за сложности.

Для сохранности данных - Бэкап! Причём в случае с USB3 - Я тупо переношу или исходный носитель или бэкап на ноутбук с USB3 и получаю свои данные, даже если «основной» комп «в руинах».

n0mad ★★★
() автор топика
Ответ на: комментарий от mord0d

USB не обеспечивает стабильное питание, потому диски могут отваливаться на какое-то время. На «обычных» файловых системах ты этого даже не заметишь, ZFS побьётся, а Btrfs вообще рассыпется и превратится в тыкву.

Скользко всё это. Всё зависит от комплектующих. На моём опыте (не один десяток лет) и обычные ATA/SATA винты - отваливались по питанию, когда контакты в разъемах ослабевали.

n0mad ★★★
() автор топика
Ответ на: комментарий от n0mad

и обычные ATA/SATA винты - отваливались по питанию, когда контакты в разъемах ослабевали

Они чаще отваливаются если блок питания выдаёт меньше, чем жрёт периферия.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Они чаще отваливаются если блок питания выдаёт меньше, чем жрёт периферия.

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

n0mad ★★★
() автор топика
Ответ на: комментарий от n0mad

Но факт остаётся фактом - это случается везде, а не только в USB.

Но с USB это случается чаще.
А опыта с ZFS у меня… Много больше десяти лет, точно уже и не вспомню.

mord0d ★★★★★
()
Ответ на: комментарий от n0mad

Но факт остаётся фактом

Это факт.

это случается везде

А это оценка, а не факт.

Не надо путать оценочное суждение с фактом. Надежность - это оценка. И у каждой системы есть своя оценка «надежности». У системы «zfs+usb» низкая оценка, выше вероятность получить в лицо фактом.

anonymous
()
Ответ на: комментарий от unC0Rr

scrub насколько помню сам избавится от этих недоступных конструкций. Потом zpool clear, чтобы убрать статус DEGRADED.

ВОТ! Учитесь у истинных ГУРУ! Комплексный ответ в паре фраз!

n0mad ★★★
() автор топика
Ответ на: комментарий от anonymous

Но факт остаётся фактом

Это факт.

это случается везде

А это оценка, а не факт.

Оценка имеет вероятность, но с разной вероятностью оно случается ВЕЗДЕ! Вот это ФАКТ!

Не надо путать оценочное суждение с фактом. Надежность - это оценка. И у каждой системы есть своя оценка «надежности». У системы «zfs+usb» низкая оценка, выше вероятность получить в лицо фактом.

Вот именно. Логично добавить к ФАКТУ оценку: «на usb+zfs этот факт происходит чаще».

Тут опять бестолковый спор из разряда: «кто круче».

n0mad ★★★
() автор топика
Ответ на: комментарий от anonymous

Сперва проверь «истину», а потом … можешь не докладывать, что потом

Я где то писал про «истину»? Я написал: «Комплексный».
1. Исправить
2. Поставить флажок что исправлено.

n0mad ★★★
() автор топика
Ответ на: комментарий от anonymous

или не случается. Не факт!

Случайность одна на одну миллиардную - может произойти в следующую секунду! Она не может не случиться. Всегда может отрубиться элекстричество, сдохнуть бесперебойник или тупо молния в провод...

Ладно, на эту тему я всё сказал!

n0mad ★★★
() автор топика
Последнее исправление: n0mad (всего исправлений: 1)

Я не очень понял какие диски в пуле. Если выведешь zpool status весь, будет лучше. Сейчас я вижу там 1 диск возможно на GPT-разделе, избыточности нет, а есть ссзб.

Как бы удалить эти конструкции

Нормально - zpool replace. Мусор - zpool detach. Если ресильвер ломался и перезапускал, может такое остаться.

Lordwind ★★★★★
()
Последнее исправление: Lordwind (всего исправлений: 1)
Ответ на: комментарий от unC0Rr

встроенного сжатия

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

шифрования

сейчас куча таких вариантов

проверки чексумм

и как ты собрался на одном диске ими пользоваться? есть конечно copies, но от отказа всего диска не защитит и для hdd словишь лулзов

снапшотов

тут да, фича знатная

zfs send

а тут жир потёк, это ж надо еще у всех клиентов поддежку zfs иметь

Lordwind ★★★★★
()
Ответ на: комментарий от Lordwind

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

Можно просто копировать файлы rsync-ом, не особо задумываясь о сжатии. zstd даст хорошую степень сжатия и быструю распаковку

сейчас куча таких вариантов

Но только один из них отлично работает с инкрементальным zfs send, в инете есть даже сервера, куда можно засылать свои шифрованные инкрементальные бекапы с помощью zfs send

и как ты собрался на одном диске ими пользоваться?

Чего ими пользоваться? zfs сама их посчитает, будешь знать, в порядке ли файлы

это ж надо еще у всех клиентов поддежку zfs иметь

Само собой, этот плюс работает только при бэкапе с zfs на zfs.

unC0Rr ★★★★★
()
Ответ на: комментарий от n0mad

Это типа - ССЗБ! Дядь, эта fs очень «любит» несколько вещей - отключение питания и отсутствие свободного места (25% для внутренних работ).

Я не знаю задач, чтобы втаскивать это на то, что написали выше. ИМХО, она открывает свой потенциал там, где вот это всё: send/receive, blah-blah…

дома ext4 - весч!

Eulenspiegel
()