- Вопрос или проблема
- Добавление запрашиваемой информации:
- Правка для добавления информации 16/02/17
- Правка для добавления информации 29/03/17
- Правка для добавления информации 13/04/17
- Ответ или решение
- 1. Неурегулированные разделы дисков
- 2. Ошибки ядра и ZFS
- 3. Экспорт и импорт пула
- 4. Замена проблемного диска
- 5. Пересоздание пула
- Заключение
Вопрос или проблема
Прежде всего, давайте начнем с того, что я использую. Это домашний медиасервер на Ubuntu 16.10. У меня есть один пул зеркальных 6-терабайтных дисков, которые заполнят примерно на половину. Я собрал систему около месяца назад, и она работает прекрасно. Он использует SSD в качестве загрузочного диска и вышеупомянутый пул в качестве хранилища. Я смог сделать все, что мне нужно, с этим пулом, и все выглядит отлично.
Оба диска были новыми, когда я собрал систему около месяца назад, и я немного обеспокоен некоторыми дополнительными вибрациями у одного из них. Ничего плохого, но продавец сказал, что заменит его бесплатно, поэтому я планировал запустить процесс проверки и вытащить его, отправив в ремонте, работая в деградированном состоянии, пока жду. На нем нет данных без резервного копирования, так что меня это не слишком беспокоит, но, конечно, было бы легче сделать это таким образом, чем убивать пул и восстанавливать его из резервной копии.
В данный момент я действительно пытаюсь просто запустить процесс проверки и безопасно отключить один диск от зеркала. Я запускаю
zpool scrub tank
и затем сразу запускаю
zpool status
и я вижу, как идет процесс проверки. Я могу запускать обновление каждые несколько секунд и видеть, как он обновляет статус без проблем. Он работает около 30 секунд, а затем статус больше не показывает, что он работает. Кроме того, я никогда не видел ничего, кроме последней проверки, завершенной за 0 часов 0 минут в статусе. Для меня это означает, что проверка не завершится, так как неужели проверка не должна занять как минимум несколько часов с двумя с половиной терабайтами информации для обработки.
Что я упускаю?
Добавление запрашиваемой информации:
pool: Tank
state: ONLINE
scan: scrub repaired 0 in 0h0m with 0 errors on Sun Feb 5 00:31:42 2017
config:
NAME STATE READ WRITE CKSUM
Tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sdb2 ONLINE 0 0 0
sdc2 ONLINE 0 0 0
errors: No known data errors
Я снова пробую проверку, чтобы убедиться, что проблема все еще актуальна. Вот статус примерно через 20 секунд после начала…
pool: Tank
state: ONLINE
scan: scrub in progress since Fri Feb 10 14:25:12 2017
62.5M scanned out of 2.97T at 1.08M/s, (scan is slow, no estimated time)
0 repaired, 0.00% done
config:
NAME STATE READ WRITE CKSUM
Tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sdb2 ONLINE 0 0 0
sdc2 ONLINE 0 0 0
errors: No known data errors
и вот он снова через минуту…
pool: Tank
state: ONLINE
scan: scrub repaired 0 in 0h1m with 0 errors on Fri Feb 10 14:27:01 2017
config:
NAME STATE READ WRITE CKSUM
Tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sdb2 ONLINE 0 0 0
sdc2 ONLINE 0 0 0
errors: No known data errors
Правка для добавления информации 16/02/17
У меня заканчивается время, чтобы вернуть “шумный” диск, поэтому я его вытащил. Я ничего не делал, кроме как отключил его (когда система работала). Все продолжает правильно функционировать в данный момент, хотя и в состоянии DEGRADED, как и ожидалось. Я думаю, я продолжу документировать свой опыт здесь, поскольку я уже начал это делать. Похоже, никто другой не сталкивается с этой проблемой. Я не могу найти никого другого в интернете с такой же ситуацией. Мне повезло. Мы увидим, что произойдет, когда я получу заменяющий диск и снова запущу процесс проверки. Кто знает… может, боги данных будут милосердны ко мне, и простая замена диска заставит проблему решить саму себя. :/ Ниже мой вывод после отключения диска.
pool: Tank
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: scrub repaired 0 in 0h1m with 0 errors on Sun Feb 12 00:24:38 2017
config:
NAME STATE READ WRITE CKSUM
Tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
sdb2 ONLINE 0 0 0
sdc2 UNAVAIL 0 0 0
errors: No known data errors
Правка для добавления информации 29/03/17
root@NAS:~# zpool status
pool: Tank
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://zfsonlinux.org/msg/ZFS-8000-9P
scan: resilvered 525M in 0h3m with 0 errors on Wed Mar 29 14:28:46 2017
config:
NAME STATE READ WRITE CKSUM
Tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sdb2 ONLINE 0 0 0
sdc ONLINE 0 0 732
errors: No known data errors
Может, еще одна подсказка о проблемах? посмотрите на раздел sdc…
root@NAS:/dev# parted --list
Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 538MB 537MB fat32 EFI System Partition boot, esp
2 538MB 233GB 232GB ext4
3 233GB 250GB 17.1GB linux-swap(v1)
Warning: Not all of the space available to /dev/sdb appears to be used, you can
fix the GPT to use all of the space (an extra 7 blocks) or continue with the
current setting?
Fix/Ignore? i
Model: ATA HGST HUH728060AL (scsi)
Disk /dev/sdb: 6001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 2097kB 2150MB 2147MB
2 2150MB 6001GB 5999GB zfs
Model: ATA HGST HUH728060AL (scsi)
Disk /dev/sdc: 6001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 6001GB 6001GB zfs zfs-802af6a53a6d8383
9 6001GB 6001GB 8389kB
Правка для добавления информации 13/04/17
Да, я пытаюсь решить эту проблему несколько месяцев :/
Во-первых, после экспорта/импорта буквы дисков изменились, поэтому учтите, что sdb стал sdc, а sdc стал sdd.
Я думаю, я нашел проблему, и хочу получить совет, как ее исправить. Проблема была наконец обнаружена, когда я запустил “sudo fdisk -l”. Ниже приведены соответствующие фрагменты…
Disk /dev/sdc: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 7127FE7D-E061-11E6-BD1F-3497F600DDAF
Device Start End Sectors Size Type
/dev/sdc1 4096 4198399 4194304 2G FreeBSD swap
/dev/sdc2 4198400 11721043967 11716845568 5.5T FreeBSD ZFS
...
Disk /dev/sdd: 5.5 TiB, 6001175126016 bytes, 11721045168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: E799A1D5-F9B7-C843-AB62-AADC9B0A2180
Device Start End Sectors Size Type
/dev/sdd1 2048 11721027583 11721025536 5.5T Solaris /usr & Apple ZFS
/dev/sdd9 11721027584 11721043967 16384 8M Solaris reserved 1
Обратите внимание на это: зеркало изначально было создано в FreeNAS (FreeBSD). У sdc есть 2 ГБ подкачки в начале диска. sdd был создан в Ubuntu, и по какой-то причине ему был дан 8 МБ подкачки в конце диска.
Теперь, опасаясь, что проблема в неисправном диске, я отключил sdd и запустил badblocks на нем. Это стирает всю информацию. Хорошая новость в том, что диск в порядке, нет плохих секторов. Это также сбрасывает разделы на ноль.
У меня есть два варианта. 1.) Попробовать вручную сопоставить разделы sdd с рабочим диском (sdc). Хотя я думал, что zfs должен делать это автоматически, просто запустив zpool replace, поэтому, возможно, это пустая трата времени. 2.) У меня есть данные на резервной копии, так что я мог бы очистить оба диска и начать с нуля, создать новое зеркало и сделать его нативным пулом Ubuntu.
Может быть, это чрезмерное размышление, но я думаю, что я рискую больше, разрушая и восстанавливая. Мне нужно уничтожить хорошие данные, которые только на резервной копии на нерезервированном диске, а затем снова rsync их обратно в вновь созданный пул. К вашему сведению, я использовал rsync для создания резервной копии, и она на том же ПК. Мне пришлось объединить 3 диска без избыточности, чтобы уместить все данные. Я также боюсь, что перемещение данных таким образом без возможности проверить это может привести к повреждению, и я никогда не узнаю.
У кого-нибудь есть советы? Спасибо!
Процесс проверки не завершается должным образом, возможно, из-за несоответствия разделов или других скрытых проблем, связанных с первоначальной установкой FreeNAS.
Во-первых, проверьте dmesg на предмет ошибок:
dmesg | grep -i zfs
Затем экспортируйте и импортируйте пул:
zpool export Tank
zpool import Tank
Убедитесь, что оба диска используют одну и ту же схему разделов. Исправьте разделы на sdc, чтобы они соответствовали sdb:
parted /dev/sdc -- mklabel gpt
parted /dev/sdc -- mkpart primary 2150MB 100%
Замените диск:
zpool replace Tank <old_drive> <new_drive>
Запустите повторную проверку пула:
zpool scrub Tank
В качестве альтернативы, вы можете создать новый пул на замещающем диске и передать данные:
zpool create NewPool mirror /dev/sdd
zfs send -R Tank | zfs receive -F NewPool
Спасибо!
Ответ или решение
Проблема несовершенной работы процесса сканирования (scrub) в ZFS может быть вызвана рядом факторов, связанных с конфигурацией ваших дисков и состоянием пула. Рассмотрим детально возможные причины и шаги по устранению проблемы.
1. Неурегулированные разделы дисков
Одной из основных причин проблемы является несоответствие разметки разделов на дисках в зеркале. В вашем случае один из дисков (sdc) имеет раздел под своп (FreeBSD swap), в то время как другой (sdd) использует только ZFS. Это может вызвать ошибки при выполнении операций с пулом, включая сканирование.
Решение: Вам необходимо убедиться, что разделы обоих дисков идентичны. Для этого вы можете использовать команду parted
для корректировки разметки:
parted /dev/sdc -- mklabel gpt
parted /dev/sdc -- mkpart primary 2150MB 100%
Эти команды создадут новую разметку GPT и создадут раздел, который соответствует разметке на другом диске. Будьте осторожны, чтобы не удалить важные данные. Ваша основная цель — синхронизировать разметку, чтобы ZFS мог корректно выполнять операции.
2. Ошибки ядра и ZFS
Чтобы выявить дополнительные проблемы, стоит проверить системные логи на наличие ошибок, связанных с ZFS. Это можно сделать с помощью команды:
dmesg | grep -i zfs
Логи могут содержать подсказки о том, какие проблемы могут мешать успешному завершению операции scrub.
3. Экспорт и импорт пула
Если после изменения разметки проблема сохраняется, попробуйте экспортировать и снова импортировать пул, чтобы обновить его состояние. Пул можно экспортировать простой командой:
zpool export Tank
А затем импортировать:
zpool import Tank
4. Замена проблемного диска
Если вы обнаружили, что один из дисков не справляется с нагрузкой или имеет ошибки, рекомендуется заменить его. Например, для замены диска выполните команду:
zpool replace Tank /dev/sdc /dev/sdd
Где /dev/sdc
— это старый проблемный диск, а /dev/sdd
— новый диск. После этой операции ZFS начнет процесс восстановления (resilver) данных на новом диске.
5. Пересоздание пула
Если ни одно из решений не сработает, вы можете рассмотреть вариант пересоздания пула. Поскольку у вас есть резервные копии данных, это будет безопасный путь. Для этого выполните:
zpool create NewPool mirror /dev/sdX /dev/sdY
После чего вы можете использовать команды zfs send
и zfs receive
для передачи данных из старого пула в новый:
zfs send -R Tank | zfs receive -F NewPool
Заключение
Здесь обозначены ключевые шаги для устранения проблемы с неоконченным сканированием ZFS. Основное внимание следует уделить корректной разметке дисков и отслеживанию ошибок, которые могут возникать в процессе. Обязательно проведите резервное копирование важных данных перед выполнением любых операций, связанных с изменением структуры пула.
Качественное поддержание и мониторинг пула ZFS позволяет избежать многих потенциальных проблем, так что следить за состоянием ваших дисков и выполнять регулярные проверки — это залог стабильной работы вашей системы хранения данных.