Пул ZFS сообщает об отсутствии устройства, но оно не отсутствует

Я использую последнюю версию Debian 7.7 x86 и ZFS на Linux

После перемещения моего компьютера в другую комнату. Если я делаю статус zpool, я получаю этот статус:

  pool: solaris
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid.  Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://zfsonlinux.org/msg/ZFS-8000-4J
scan: none requested
config:

NAME                                            STATE     READ WRITE CKSUM
solaris                                         DEGRADED     0     0     0
  raidz1-0                                      DEGRADED     0     0     0
    11552884637030026506                        UNAVAIL      0     0     0  was /dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN1221F308BR3D-part1
    ata-Hitachi_HDS723020BLA642_MN1221F308D55D  ONLINE       0     0     0
    ata-Hitachi_HDS723020BLA642_MN1220F30N4JED  ONLINE       0     0     0
    ata-Hitachi_HDS723020BLA642_MN1220F30N4B2D  ONLINE       0     0     0
    ata-Hitachi_HDS723020BLA642_MN1220F30JBJ8D  ONLINE       0     0     0

Диск, в котором указано, что он недоступен, - это / dev / sdb1. После небольшого исследования я обнаружил, что ata-Hitachi_HDS723020BLA642_MN1221F308BR3D-part1 - это просто улыбка для / dev / sdb1, и она действительно существует:

lrwxrwxrwx 1 root root 10 Jan  3 14:49 /dev/disk/by-id/ata-Hitachi_HDS723020BLA642_MN1221F308BR3D-part1 -> ../../sdb1

Если я проверю умный статус, например:

# smartctl -H /dev/sdb
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Диск есть. Я могу сделать на нем fdisk и все остальное.

Если я попытаюсь отсоединить его, например:

zpool detach solaris 11552884637030026506
cannot detach 11552884637030026506: only applicable to mirror and replacing vdevs

Я также пробовал с / dev / sdb / dev / sdb1 и длинным именем по идентификатору. Все время одна и та же ошибка.

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

Если я не заменю сам жесткий диск, я не вижу никакого решения этой проблемы.

Идеи?

[обновление] отказался

# blkid 
/dev/mapper/q-swap_1: UUID="9e611158-5cbe-45d7-9abb-11f3ea6c7c15" TYPE="swap" 
/dev/sda5: UUID="OeR8Fg-sj0s-H8Yb-32oy-8nKP-c7Ga-u3lOAf" TYPE="LVM2_member" 
/dev/sdb1: UUID="a515e58f-1e03-46c7-767a-e8328ac945a1" UUID_SUB="7ceeedea-aaee-77f4-d66d-4be020930684" LABEL="q.heima.net:0" TYPE="linux_raid_member" 
/dev/sdf1: LABEL="solaris" UUID="2024677860951158806" UUID_SUB="9314525646988684217" TYPE="zfs_member" 
/dev/sda1: UUID="6dfd5546-00ca-43e1-bdb7-b8deff84c108" TYPE="ext2" 
/dev/sdd1: LABEL="solaris" UUID="2024677860951158806" UUID_SUB="1776290389972032936" TYPE="zfs_member" 
/dev/sdc1: LABEL="solaris" UUID="2024677860951158806" UUID_SUB="2569788348225190974" TYPE="zfs_member" 
/dev/sde1: LABEL="solaris" UUID="2024677860951158806" UUID_SUB="10515322564962014006" TYPE="zfs_member" 
/dev/mapper/q-root: UUID="07ebd258-840d-4bc2-9540-657074874067" TYPE="ext4"

После отключения mdadm и перезагрузки эта проблема вернулась. Не уверен, почему sdb помечен как linux_raid_member. Как это очистить?

Просто запустите zpool clear solaris затем опубликуйте результат zpool status -v.

Было бы неплохо узнать, какое оборудование задействовано и какой контроллер вы используете.

редактировать

Глядя на твою blkid вывод, у вас есть остатки предыдущего программного RAID Linux. Вам нужно будет mdadm --zero-superblock /dev/sdb1 чтобы очистить это.

После поиска в Интернете и неисправности сервера и переполнения стека в течение более дня, ничего не обнаружив. Я задаю этот вопрос, и ответ появляется в соответствующих вопросах справа. Вот и я нашел ответ на этот вопрос:

Обновленный Ubuntu, все диски в одном zpool отмечены как недоступные

По какой-то причине madam запускается в начале и запускает md0, хотя md0 не содержит дисков (как показано в ошибках), это вызывает эту ошибку.

Так что простой

mdadm --stop /dev/md0

Сделали свое дело, и теперь мои диски восстанавливаются. Дело закрыто.

Я знаю, что это вопрос пятилетней давности, и ваша непосредственная проблема была решена. Но это один из немногих конкретных результатов поиска, которые появляются в веб-поиске по отсутствующим устройствам ZFS (по крайней мере, по ключевым словам, которые я использовал), и это может помочь другим узнать об этом:

Эта конкретная проблема «пропажи» устройств является известной проблемой ZFS в Linux. (В частности, в Linux.) Я считаю, что проблема двоякая, и хотя команда ZOL могла бы сама исправить ее (вероятно, с большим трудом), это не так. полностью проблема ZOL:

Хотя ни одна ОС не имеет абсолютно стабильного способа обращения к устройствам, для этого конкретного случая использования Linux немного хуже, чем, скажем, Illumos, BSD или Solaris. Конечно, у нас есть идентификаторы устройств, GUID и даже лучше - новый стандарт WWN. Но проблема в том, что некоторые контроллеры хранения - в частности, некоторые контроллеры USB (v3 и 4), eSATA и другие, а также многие типы внешних корпусов потребительского уровня - либо не всегда их видят, либо, что еще хуже, не не передавать их в ОС. Простое подключение кабеля к «неправильному» порту внешнего корпуса может вызвать эту проблему в ZFS, и от нее никуда не деться.
ZOL по какой-то причине не может определить, что диски действительно существуют и видны ОС, просто не в любом из предыдущих местоположений, которые ZFS знала ранее (например, / dev, / dev / disk / by-id, by-path , by-guid и т. д.) Или одно конкретное предыдущее местоположение, более к делу. Даже если вы выполните правильный экспорт zpool перед перемещением чего-либо. Это особенно расстраивает ZOL или ZFS в частности. (Я помню эту проблему даже на Solaris, но при условии, что это была значительно более старая версия ZFS, которая потеряла бы весь пул, если бы ZIL пропал ... из-за чего я потерял все однажды [но имел резервные копии].)

Очевидный обходной путь - не использовать потребительское оборудование с ZFS, особенно Внешние корпуса потребительского уровня, которые используют какой-либо протокол потребительского уровня, такой как USB, Firewire, eSATA и т. д. (Внешний SAS должен подойти).

Именно это - внешние корпуса потребительского уровня - доставляет мне нескончаемые головные боли. Хотя у меня иногда возникала эта конкретная проблема с чуть большим количеством контроллеров LSI SAS «корпоративного класса» и шасси для монтажа в стойку с отсеком 5x4, переход к более портативному решению с тремя внешними отсеками в значительной степени развязал ад. К счастью, мой массив представляет собой полосу из трехсторонних зеркал, потому что в какой-то момент он буквально потерял след 8 дисков (из 12), и единственным решением было их перенести. (Которая в основном считывалась со скоростью ГБ / с, поэтому, по крайней мере, это не занимало дней или недель.)

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

Но я думаю, что если бы ZFS провела более исчерпывающий поиск метаданных, которыми ZFS управляет сама на каждом диске, это решило бы многие связанные проблемы. (Btrfs, например, вообще не страдает от этой проблемы. Я могу перемещать вещи волей-неволей совершенно случайно, и он ни разу не пожаловался. Конечно, у Btrfs есть другие недостатки по сравнению с ZFS (список плюсов и минусы бесконечны), и это также родной Linux - но, по крайней мере, показывает, что проблема жестяная банкаТеоретически решается, по крайней мере, в Linux, в частности, самим ПО.

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

Выключите внешние корпуса, чтобы ZFS не импортировала пул автоматически. (Вызывает разочарование то, что, похоже, до сих пор нет способа запретить ZFS делать это. Переименование файла кеша или установка для него значения «none» не работают. Даже без проблем с адресацией я почти никогда не хочу, чтобы пулы автоматически запускались. mount, но предпочел бы, чтобы это делал автоматический скрипт.)
Как только система встанет и стабилизируется, включите внешние шкафы.
Запустите сценарий, который экспортирует и импортирует пул несколько раз подряд (к сожалению, иногда необходимо, чтобы он видел даже допустимые незначительные изменения). Здесь самое главное - импорт в режиме только для чтения чтобы избежать автоматического срабатывания резильвера.
Затем сценарий показывает пользователю вывод zpool status пула только для чтения и спросить пользователя, можно ли продолжить импорт в полном режиме чтения-записи.

Это спасло меня (или мои данные) бесчисленное количество раз. Обычно это означает, что мне нужно перемещать диски и / или просто кабели, пока адресация не вернется на прежнее место. Это также дает мне возможность попробовать разные методы адресации с ключом -d. Некоторая комбинация этого и смена кабелей / мест несколько раз решала проблему.

В моем конкретном случае установка с -d /dev/disk/by-path обычно оптимальный выбор. Потому что мой бывший фаворит, -d /dev/disk/by-id на самом деле довольно ненадежен с моей текущей настройкой. Обычно целый отсек для дисков просто полностью отсутствует в /dev/disk/by-id каталог. (И в этом случае трудно винить даже Linux. Это просто шаткая установка, которая еще больше усугубляет существующие недостатки, отмеченные ранее.)

Конечно, это означает, что нельзя полагаться на автоматический запуск сервера без ручного вмешательства. Но учитывая, 1) он работает постоянно от большой резервной батареи, 2) я сознательно пошел на этот компромисс в пользу возможности использовать оборудование потребительского уровня, которое не требует для перемещения двух человек и тележки ... Это нормальный компромисс.

(Изменить: исправления.)