forum.lissyara.su

Mobilesfinks писал(а):да диски живее всех живых. Прогон викторией дал 3 бэда на одном и 2 на другом. И это софтовые бэды.
С одного копию снял, копия не монтируется. Со второго копия вместо 500гигов снялась всего 140гигов и всё.
Соответственно эта копия тоже не монтируется.
Диск смог подмонтировать в режиме readonly, но там ПУСТО. папка public есть, а в ней ничего нет ))

Короче файловая система ZFS это шлак какой то. Ни данные вытащить, ни восстановить. Я поражаюсь, что её ещё считают дико надёжной.
3 бэдлока убили весь пул - это круто!

Гы-гы-гы.... Диск не читается даже посекторно, а виновата zfs
Прекрасные диски

Отправлено спустя 9 минут 5 секунд:
Такая аналогия - если вам забить в висок гвоздик, пятидесятку, например - с вероятностью процентов 30 вы помрёте, ещё с такой же - с головой плохо станет.

Надо кричать - какой плохой у вас мозг? Повреждено-то несколько десятых, а то и сотых долей процента нейронов. Да ещё и тока в одном полушарии....

Alex, но все же согласись, zfs не хватает инструментов анализа сбоев... Простейшего ремонта...

Угу. А с мозгами, вообще проблема... Мало что без последствий можно сделать

Пул импортнуть можно, чё-то пофиксить по мелочи...


А на всё остальное - есть бэкап

Диск не читается даже посекторно, а виновата zfs

Второй диск не читался из-за битого шлейфа. Но с него всё равно ничего не получается снять т.к. I/O error при попытке импорта.

Пул импортнуть можно, чё-то пофиксить по мелочи...

На диске есть 4 метки, одна битая и из-за этого не импортируется - нахрена их четырые если пул не импортируется с одно битой?
Пул импортнул в режиме readonly - в точке монтирования пусто, хотя написано, что место занято. Зачем 4 метки, если даже прибитой одной, данные пропадают?
Выше тов. snorlov правильно написал "zfs не хватает инструментов анализа сбоев... Простейшего ремонта..."
Смотнирован пул, данных нет. Как вытащить данные? Alex Keda если вы такой специалист по zfs, то прошу подсказать КАК вытащить данные с импортрованного пула? Или как этот пул починить?

При чём тут мозги то? Я выше писал, что используя другую FS, вероятность сохранить данные гораздо выше чем при использовании ZFS, но вам не понравилось это видимо?

А на всё остальное - есть бэкап

С этим не поспоришь. Отчасти мой недосмотр, но у меня там и не было задачи бэкапить, сами они этим занимались.
Так вытащить то данные можно? или стебаться будем?

у меня на корзине md-raid6
так вот недавно при ребилде вылетели еще 2 диска
и все, хана данным...
так что ZFS тут или другая ФС монописуально

snorlov писал(а):Alex, но все же согласись, zfs не хватает инструментов анализа сбоев... Простейшего ремонта...

о чем речь народ?!

"простейший ремонт" - возможен для простейшей или несложной FS, ZFS - больше чем просто FS.
Изначально предусмотрены snaphost'ы и везде пишут - потеря вынесенного журнала, загибание
диска - "жопа". Кроме того, эта жопа зависит от типа и конфигурации пула, наличие резерва
под него и тд и тп.
Изначально, дано ВСЕ - выбор за тем кто его делает, ну а далее - имеем то что имеем.

Сложность "унутренной системы сгорания" не предусматривает простейшего ремонта в случае
загнувшегося диска! А для незагнувшегося: море инструментов и для пула и для dataset,
но все они требуют слежения.

Так что, изначально для проекта нужно правильно выбрать FS, если не предумотрено слежения за HDD:

linux:
- ext2/ext3 (boot)
- ext4 (root + data)
без lvm/mdadm

freebsd:
- ufs2/ufs2-su (root)
- ufs2-su/ufs2-suj? (data)

вот в этих случаях можно биться с inodes с определением bad, выведением inode из FS,
с victoria, с dd на image и только в случае если диск не сыпет регулярными errors и controllers interrupt

наличие frameworks (прослоек) между HDD <- [lvm/mdmadm/geom] - усложняет руковосстановление.
А zfs - имеет уже в СЕБЕ эти прослойки: пулы и dataset и кучу изначальных настроек для
замены HDD, которые зависят от вышеизложенных факторов.

To TC: sorry, трудно что-то подсказать, с этим лучше в freebsd списки или в illumos.

ладно, спасибо за разъяснение. Да я особо и не выбирал - во FreeNAS оно как бы по умолчанию используется. Думаю всё же ценность zfs переоценена.

Возможно, но очень удобно манипулировать с данными, красиво и быстро делаются снапшоты, сами снапшоты при пересылки не грузят систему, что касается состояния, то у меня в тестовой конфигурации, что я только с ней не делал, к примеру перед тем как вылететь всему пулу, сначала из него вылетел один диск, я это вовремя увидел и заменил его без танцев с бубнами, автору темы вместо использования zdb, надо было просто вставить новый диск разметить его так же как и сбойный, затем дать replace, убедиться что пошел процесс восстановления resilvering, затем смотрим на статус пула online и лишь затем detach сбоившего диска...

Mobilesfinks писал(а):ладно, спасибо за разъяснение. Да я особо и не выбирал - во FreeNAS оно как бы по умолчанию используется. Думаю всё же ценность zfs переоценена.

ценность zfs не оспорима, а вот GUI системы а-ля: NAS, Router и тд и тп,
переоценивают подготовку администраторов, которые получая мыше-кнопочный
инструментарий, забывают про реальную работу и слежение ДАЖЕ за ГУЕВОЙ системой.

выбор типа raidz - заведомо определяет возможность замены диска/ов, а использовать zfs как raid0
не очень умно, в данном случае, ufs быстрей и проще.

Типа: довести зуб до состояния, когда лечение не возможно - только драть.

ps. Вот то что NAS'ы на базе FreeBSD перестали давать возможность использовать UFS, бяда - согласен.

а использовать zfs как raid0

Я как бы выбирал mirror, а raid0 это слишком для специфичных задач и как бы не сильно помогает сохранить данные ))

ps. Вот то что NAS'ы на базе FreeBSD перестали давать возможность использовать UFS, бяда - согласен.

Да, до этого у меня стоял чистый FreeBSD 8 + gmirror + ufs - вылет диска не сломал ничего, думал апгрейд на FreeNAS поможет в какой то мере, но прогадал. Не та контора что бы следить, я туда раз в год/полгода прихожу так что была надежда на надёжность файловой системы. Теперь впредь буду мутить оповещалки на такие площадки.
А raid0 - не, не. Только raid1 под такие задачи.

Тема отделена от восстановление данных с развалилвшгегося ZFS pool, если кто горит желанием помочь по делу, айда туда.
Тут можно продолжать флудить по объявленой теме, хотя как по мне, сравнение плоского с длинным бессмысленно по определению. ZFS больше про бесперебойность, ну и да следить за ним недурно, как и за любой навороченной штукой.

вот после таких деяний, обычно утухают обе темы ...