Раз у нас разбор полётов - давайте на практике.
Предисловие
Возникает проблема с диском. Камрад пишет.
NAS не загрузился (см. скриншот - и так долго все происходит, но не загружается).
В чем может быть проблема? Не читается ada3?
Всё правильно - проблема с диском. Каким именно - стоит определить, в идеале взглянув на его SMART Diagnostics|Information|S.M.A.R.T. У проблемного диска особенно интересны параметры
5 Reallocated_Sector_Ct 196 Reallocated_Event_Count 197 Current_Pending_Sector 199 UDMA_CRC_Error_Count
Смысл примерно одинаковый у всех производителей.
5 параметр отличный от нуля - плохой признак. Но бывают диски, которые набрав несколько плохих блоков, затем годами нормально работают. У меня такой есть. Очень плохо, если этот параметр растёт. Диск готовится к путешествию в страну вечной охоты, которое может начать и через неделю и через минуту.
Ненулевые, растущие три остальных параметра могут означать как реальные проблемы с диском, так и проблемы с SATA кабелем. Последнее намного вероятнее и я настоятельно советую начать с замены кабеля.Стоят они недорого, нервы дороже. При большом желании можно вытащить диск из NAS и прогнать тест поверхности какой-нибудь Викторией. Но я этого не делаю. Проще прогнать SMART тесты типа
nas4free ~/ root~$ smartctl -t short /dev/ada0 smartctl 6.3 2014-07-26 r3976 [FreeBSD 9.3-RELEASE-p9 amd64] (local build) Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === Sending command: "Execute SMART Short self-test routine immediately in off-line mode". Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful. Testing has begun. Please wait 2 minutes for test to complete. Test will complete after Mon Mar 16 00:15:22 2015 Use smartctl -X to abort test.
Результат в вебгуе проще взглянуть
SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 25543 -
если вместо short задать long - будет длинный тест,
Прим. С очень малой вероятностью проблемы могут быть с несовместимостью диска и контроллера. Хотя у меня на практике такое было, рассматривать этот вариант всерьёз не советую.
Отключать или нет сбойный диск zfs массива при замене
Предположим, оказалось, что виновен именно диск. Есть два варианта - (А) отключить его, подключить вместо него новый, провести замену. (Б) оставить сбойный диск, подключить на другой SATA порт новый, провести замену, отключить сбойный диск.
Вариант А проще, позволяет забрать диск, поменять по гарантии, заменять на него. Но есть важный недостаток. В случае raidz (или одиночного зеркала) в прцессе замены ваши данные - без избыточности. Сбой в процессе замены, а это часы, - и часть данных может быть потеряна.
Вариант Б сложнее, требует свободного (хоят бы временно) SATA порта и диска из подменного фонда. Но есть важный плюс - данные в процессе замены имеют избыточность. Каждый блок достаточно прочитать либо со сбойного диска, либо с остальных. Единичный сбой не страшен.
Обычно исходят из того, что данные ценнее дисков. Поэтому вариант Б выглядит предпочтительным. Но есть детали.
Если диск сбоит сильно, то процесс замены значительно затягивается. Это увеличивает риск сбоя остальных дисков массива. Поэтому придётся как-то на глаз оценить плюсы и минусы. Пожалуй, если у нас RAIDZ2, способный выдержать выход из строя двух дисков - то цепляться за сбоящий диск смысла нет. Разумно идти по варианту А - избыточность ведь сохраняется.
А если raidz или простое зеркало - то решение принять труднее. Я бы пытался сохранить избыточность до последнего, пока диск колом не встал. А если встанет - отключил бы от него питание.
У камрада, с вопроса которого мы начинали обсуждение, диск сдох навовсе. Поэтому он подключил новый диск на его место и дал нам хороший пример наиболее вероятного развития событий.
nas4free ~/ root~$ zpool status Data
pool: Data
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Sat Mar 14 10:55:23 2015
2.74T scanned out of 4.09T at 285M/s, 1h22m to go
702G resilvered, 67.04% done
config:
NAME STATE READ WRITE CKSUM
Data DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ada1 ONLINE 0 0 0
ada4 ONLINE 0 0 0
replacing-2 DEGRADED 0 0 0
8577650223873339884 OFFLINE 0 0 0 was /dev/ada3/old
ada3 ONLINE 0 0 0 (resilvering)
ada2 ONLINE 0 0 0
errors: 1 data errors, use '-v' for a listЧто мы здесь видим?
- Бывший диск /dev/ada3 имел zfs идентификатор 8577650223873339884. Этот ID, кстати, запросто можно использовать в командах zpool.
- он заменяется на новый диск, который теперь ada3
- у нас ранее вылезла какая-то ошибка, которая могла привести к потере данных.
Забегая вперёд скажу, что в нашем случае к счастью ошибка пришлась на малоценный файл, который был удалён. Если бы избыточность сохранилась - мы бы его не потеряли.
Ну а после завершения картинка - заглядение.
nas4free ~/ root~$ zpool status Data
pool: Data
state: ONLINE
status: The pool is formatted using a legacy on-disk format. The pool can
still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
pool will no longer be accessible on software that does not support feature
flags.
scan: resilvered 1.02T in 4h43m with 0 errors on Sat Mar 14 15:38:46 2015
config:
NAME STATE READ WRITE CKSUM
Data ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
ada1 ONLINE 0 0 0
ada4 ONLINE 0 0 0
ada3 ONLINE 0 0 0
ada2 ONLINE 0 0 0
errors: No known data errors На предупреждение "The pool is formatted using a legacy on-disk format" можно особого внимания не обращать. Да и другая это тема.
UPD от 16 марта 2015
Камрад RU_Taurus поделился своим свежим опытом по обсуждаемому вопросу.
См полностью здесь и последующие три поста.
С сокращениями
RU_Taurus: У меня двушку мучал до талого, она кстати в процессе окончательно сдохла.
MikeMac: Очень интересно - при полностью сдохшем в процесс диске система сама его отключила, потребовалось ручное отключение или всё встало колом?
RU_Taurus: Ничего из этого. Просто чтение с диска стало очень медленным, но он до конца оставался доступным. Во время ресильвера система сначала пыталась вычитывать умирающий диск, когда ей это не удавалось, то данные восстанавливались за счет избыточности (всего в поле CKSUM было более 1500 ошибок).
Именно в начале данного процесса я и написал свой пост о необходимости пересмотра совета о подключении умирающего диска для случая raidz2 и выше. Так же был пост о прогрессе ресильвера. Большое влияние запущенной и используемой самбы - подтверждаю, повторно запускал SMB и смотрел что-то с пула, скорость ресильвера при этом опять упала где-то к 20МБ/сек. Потому все лишние сервисы на время ресильвера лучше отключать.
/UPD