Смачно навернулась zfs. Что бы можно попробовать сделать?

zpool import -F

Jessie x32

ты хотел сказать x86_32, т.е i686?

Можно попробовать на чистой машине BSD import-export

ты хотел сказать x86_32, т.е i686?

Ну да. На других я не работал. Лишь x86 32 и 64...

Можно попробовать на чистой машине BSD import-export

Для этого нужна чистая машина BSD.

Пока хочу с USB загрузить Jessie с zfs и сделать import/export

zpool import -F

Те же яйца...

Ссзб если ты зфс на x86_32 крутишь

Jessie с zfs

Если ты пул zfsonlinux создавал, то им и ковыряй. Что у тебя там в jessie fuse zfs? И да, тут правильно говорят, zfs только на x64.

Ссзб если ты зфс на x86_32 крутишь

Всё относительно. На x86_64 я начал крутить во времена zfsonlinux, а на x86_32 он не работает. zfs-fuse начал работать но у меня машинка ещё со времен zfsonlinux.

zfs не таким уж непадучим оказался... (Вернее сам то zfs может и не упал - а вот линуховая тулза падает при анализе неисправности...) Лёг при отключении питания на высокой нагрузке. (allocating allocated segment)

х32 она не должна корректно работать. Разработчик ее пилит только по х64.

Скорее версии разные.

zpool status -v покажи по пулу?

Еще можно переименовать файлик zpool.cache
Команда zpool get cachefile покажет где он находится.

zpool import
потом по id импортируй.
Одно из двух должно прокатить.

zpool status -v покажи по пулу?

# zpool import
pool: S160-zfs
id: 3571482422731546213
state: ONLINE
status: Some supported features are not enabled on the pool.
action: The pool can be imported using its name or numeric identifier, though
some features will not be available without an explicit 'zpool upgrade'.
config:

S160-zfs ONLINE
S160-zfs ONLINE

# zpool status -v S160-zfs
cannot open 'S160-zfs': no such pool
root@Zer0:~#

Или я что то не так делаю? Импортировать пул не могу - паника наступает.

Еще можно переименовать файлик zpool.cache

Команда zpool get cachefile покажет где он находится.

#zpool get cachefile
NAME PROPERTY VALUE SOURCE
IOM2T-store cachefile - default
NAS3T-pub cachefile - default

Эта команда показала вообще имена рабочих экспортированных пулов.

Так что с импортом пока облом.

Сейчас переименую /etc/zfs/zpool.cache

Хм... не знаю после переименования или совпало - при рестарте:
[*** ] A start job is running for Import ZFS pools by device scanning (XXXs/no limit)[ 25.203021] PANIC: zfs: allocating allocated segment..... и секунды идут (видимо до no limit)

Дисками не дрыгает а секунды идут...
C-A-D

Файл /etc/zfs/zpool.cache создался заново.

#zpool import -F S160-zfs

Message from syslogd@Host at Feb 17 22:16:41 ...
kernel:[ 177.831864] PANIC: zfs: allocating allocated segment(offset=24705945600 size=73728)

Message from syslogd@Host at Feb 17 22:16:41 ...
kernel:[ 177.831864]

вот так... убить файл - случится авточек и он создастся.
Хотя... сейчас убью и сразу импорт... без перезагрузки.

DO-IT - Те же йяцы...

А тем временем поспела USB Jessie+zfs...

А тем временем поспела USB Jessie+zfs...

И у этой Джесси те же яйца... zfsные...

Первая загрузка - бесконечный импорт (выпавший в панику)
После перезагрузки отработка у zfs хороша - не пускает повторно в панику а даёт системе загрузиться и в панику лишь если мануально импортировать...

В общем систему пока поднять не удаётся... Придётся пока поставить на какой нибудьстаренький IDE до завершения разборок. Радует хоть что Пулы 3Т и 2Т остались живы...

Тогда потри кэш и zpool import -o readonly=on

zpool import -F

Не поможет. Тут внутренняя неконсистентность метаданных

zpool import -o readonly=on

а вот это хороший совет

вот так... убить файл - случится авточек и он создастся

Это и должно было произойти.

zpool import 3571482422731546213

Не прокатит так - вопросы к разработчикам.

Тогда потри кэш и zpool import -o readonly=on

О! СПАСИБО ДОБРЫЙ ЧЕЛОВЕК!
Убил кучу времени на создания USB винтов для починки а с них не починишь... там нужные катклоги всё равно не пусты. Грузанулся в реальную систему, подмонтировал. Сейчас пытаюсь всё вынести на USB винт а потом пересоздать раздел.
Как просто ларчик открывался.... жаль что не просто починило а мувить-мувить... но хоть так.

Значит что-то с версиями ZFS не то было, что readonly помог.
Вообще, ZoL не рекомендую использовать. Пока что это недоделка.

Уж года два как ZoL на серверах трудится, виртуалки и контейнеры на ней живут. Серверов много, нагрузки по io приличные. Да и proxmox ZoL официально поддерживает.

Самое отвратительное, что ты

zfs поставил давно, на Debian Wheezy

но так и не изучил мат.часть того, что ты себе поставил. Вот и огреб с позором.

уйти в гибернейт.

СЗЗБ чо.

Вообще, ZoL не рекомендую использовать. Пока что это недоделка.

А что использовать? ext4?
Вообще в компьютерном мире одни недодоелки...
Их всё делают, делают, делают...

но так и не изучил мат.часть того, что ты себе поставил. Вот и огреб с позором.

До сих пор оно работало без нареканий и глубокое знание мат.части не требовалось.
Сейчас оно бахнуло - но сразу нашлись преимущества. Ридонли то подмонтировалось, дало всё забрать и сейчас насоздавал подразделы, назначил точки монтирования туда где они и были - сейчас буду лить на них.

уйти в гибернейт.

СЗЗБ чо.

Голь на выдумку хитра. Ну нет у меня портативного дизель генератора - а UPS держит недолго и до сих пор спасало нажатие на кнопку Power - отправляющее машинку в гибернейт. Как электричество восстановят - опять нажатие Power возвращало прежнее состояние (Линукс у меня на десктопе и на нём ещё 9 виртуальных столов...)

Тогда потри кэш и zpool import -o readonly=on

Но есть у этого решения серьёзный минус:
readonly может монтировать лишь на прежние точки (или я не нашел как, мне не позволяло изменить mountpoint для r/o).
Можно было бы смонтировать «в сторонку», создать новые точки и всё туда скопировать...
Мне же пришлось смонтировать всё r/o туда где было, скопировать «в сторонку», перезагрузиться и создав такю же структуру из «сторонки» вернуть назад.

Ну вот и я снова с вами с привычного окружения из 60 вкладок в 22 окнах... Я интернете не по закладкам хожу - а по виртуальным окнам на десктопе :)

zfs оправдала своё назначение - быть нерушимой.
Знать бы сразу алгоритм - простой был бы гораздо меньше.
Итак алгоритм:

#zpool import -o readonly=on S160-zfs
(оно смонтировало всё на свои места но read-only)
#zfs create NAS-store/S160-zfs
(Создал подтом на диске для бэкапа)
rsync -axvPH /home/ /S160-zfs
rsync -axvPH /var/lib/mlocate/ /S160-zfs
...
(Скопировал данные во временное хранилище)
Перезагрузился.
Создал прежние точки (какие были на S160-zfs)
Скопировал из временого хранилища назад.
Сделал контрольную перезагрузку.
Пишу отчёт.

Минус у тебя, в незнании. Можно было смонтировать куда угодно! Достаточно было man прочитать
-o mntopts
Comma-separated list of mount options to use when mounting datasets within the pool. See zfs(8) for a description of dataset properties and mount options.

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

Мануал читать надо чаще.

Заодно терминологию подтянешь.

Подтома (subvolume) это в btrfs, в zfs - dataset.

Можно было бы смонтировать «в сторонку», создать новые точки и всё туда скопировать...

Открой для себя опцию -R для zpool import

«Отличный пилот это тот, кто использует отличное мышление, избегая ситуаций когда требуется отличное умение.»

В прямых руках и страус полетит. :)

А вот то что в Проксмокс появилась поддержка zfs ничего не значит.

Ибо падает ядро на том же железе, где фря в своём недопиленном гипервизоре преспокойно крутит те же виртуалки. Причём падает именно из за zfs, так как на xfs и ext4 все ок.

Ибо падает ядро на том же железе

У меня не падает. Пользую ubuntu 14.04 lts и centos 7.

Каким же надо быть задротом, чтобы на домашнем компьютере разворачивать эту неведомую мрачную фигню?

Лишь x86 32

ты походу маны то не читал.

Минус у тебя, в незнании. Можно было смонтировать куда угодно! Достаточно было man прочитать

Увы ман я не читал. Каюсь!

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

Такова жизнь. Приходится браться, копаться и изучать.

Мануал читать надо чаще.
Заодно терминологию подтянешь.
Подтома (subvolume) это в btrfs, в zfs - dataset.

Увы у меня всё на порядок сложнее.
Чтобы запомнить - надо прочитать далеко не один раз.
(Травма мозга как у Михаэля Шумахера).

Открой для себя опцию -R для zpool import

Спасибо что подсказываете очевидные вещи.
Я их увы не всегда осознаю.

Каким же надо быть задротом, чтобы на домашнем компьютере разворачивать эту неведомую мрачную фигню?

Мне повеситься? Чтобы не быть задротом...
Я писал выше...

ты походу маны то не читал.

При чём тут маны? Я общаюсь лишь с x86_32 и x86_64

там ясно написано что на 32 zfs нестабильна и бессмысленна

там ясно написано что на 32 zfs нестабильна и бессмысленна

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

там ясно написано что на 32 zfs нестабильна и бессмысленна

А уж как оно лопает проц на x64... при gzip-9 сжатии - жесть.
Ноут с i5 вис вусмерть а десктоп вешал процесс синка.
Проц ноута грелся до 65 градусов...
(При массированном rsync с винта на винт)

Ну нет у меня портативного дизель генератора - а UPS держит недолго и до сих пор спасало нажатие на кнопку Power - отправляющее машинку в гибернейт.

Network UPS Tools, например, умеет отправлять систему в гибернейт через несколько минут (или секунд, можно настроить). Этого должно хватить пока ИБП не отрубится. По крайней мере у меня так.

При массированном rsync

потому что для этого есть zfs send|zfs recv

Network UPS Tools, например, умеет отправлять систему в гибернейт через несколько минут (или секунд, можно настроить). Этого должно хватить пока ИБП не отрубится. По крайней мере у меня так.

У меня было всё при моём нахождении за компом и я сразу даванул Power.
Оно пошло гибернейтиться. Но у меня же ещё и пакованный zfs - который из 8G рамы берет под кэши 6.7 после #du -sh на 3T разделах (Это был тест). Так вот за пару недель аптайма всё как то сурово становится. Гибернейтиться может пару минут и UPS этого у меня не выдержал.

А по поводу nut отдельный разговор. В варианте десктопа с MATE есть такая штука как $gsettings и там есть:

org.mate.power-manager action-critical-ups 'hibernate'
org.mate.power-manager sleep-display-ups 60
org.mate.power-manager sleep-computer-ups 0
org.mate.power-manager action-low-ups 'hibernate'

org.mate.power-manager time-critical 300

Есть подозрение что это надо секунд в 10 поставить... иначе при включенном шлейфе UPS - при отключении сети компьютер не реагирует на кнопку Power, а 300 секунд UPS не выдерживает.

org.mate.power-manager sleep-computer-ac 0

Вот с этим не знаю что делать. Ещё не гуглил...

org.mate.power-manager percentage-critical 3

И это онаверное до 50 надо поднять... с 3% Видимо загибернейтиться не сможет.

Впрочем это от рута, а от юзера ещё не сравнивал.
Есть подозрение что поведение разное для разных активных юзеров.

В общем я пока с этим не разобрался - но nut тут не катит. Получались какие то конфликты между ним и гномом. В разных ситуациях верх брали то один то другой.

Вот как то так. Линукс на десктопе - штука суровая. Уж сколько крови у меня выпили слип и гибернейт... Я долго ими пытался рулить из конфигов - но потом выяснилось что на десктопе ноги растут из gsettings но и конфиги тоже своё дело делают. в итоге скажем на слип срабатывают и конфиги и gsettings, но кто то из них усыплят другого и при включении второй просыпается и доделывает дело (опять слипает/гибернейтит).

Понаделали в Линуксе своего регистри... С одной стороны хорошо (всё в одном конфиге и рулится с командной строки) а с другой - не понятно какая подсистема будет отрабатывать в каком из случаев. Они же параллельно работают...

потому что для этого есть zfs send|zfs recv

Спасибо. На досуге покурю маны. Пока не понимаю это zfs<->zfs или для любой fs?
Просто висняки у меня были когда я с обычной fs синкал на пакующую zfs/gzip-9 Мои рсинки между 3T zfs пока работают, но это 1.5часа. zfs send|zfs recv можно делать между рсинкнутыми перед этим zfs? Или оно с нуля только и только этими тулзами?

Линукс на десктопе - штука суровая. Уж сколько крови у меня выпили слип и гибернейт...

В моем случае это скорее производительность ЦП и графики. Какая-то она слабоватая в сравнении с производительностью на Windows. Будто что-то где-то сдерживает, хотя частоты везде максимальные и блоб невидии.

С zfs на zfs или в/из файл(а). Можно хоть cat 'mycoolzfs.img | zfs recv'.

С zfs на zfs или в/из файл(а). Можно хоть cat 'mycoolzfs.img | zfs recv'.

Курил маны и нифига не понял...
Пока боязно переходить на zfs send|receive сначала нужны тестовые прогоны дабы понять... Не хочу потерять свой текущий рсинк в случае ошибок.

Насколько я понял - zfs send|receive не делает анализов а тупо шлёт всю систему в первый раз а потом то что изменилось от снапшота до снапшота. т.е. надо четко следить что и куда льёшь - иначе можно что то не то и не туда вылить.

с rsync всё гораздо проще и предсказуемее - он просто делает зеркало... и без разницы что было «до» - он приведёт всё в синхронизацию.

Пусть для 3Т zfs тома это не оптимально, но 1.5 часа и результат получен.

В случае с zfs send|receive я так и не понял можно ли получить инкремент от того что есть или всё надо заново лить полностью (3Т)

zfs send делает ровно то, что ты его попросишь. Можно попросить послать состояние датасета, зафиксированное в любом из снимком, можно попросить послать дельту между двумя произвольными снимками одного и того же датасета, с гораздо меньшим оверхедом, чем при синхронизации rsync'ом.