Я вижу несоответствие между выводом mdadm --detail и mdadm --examine, и я не понимаю, почему.
Этот вывод
mdadm --detail /dev/md2
/dev/md2:
Version : 0.90
Creation Time : Wed Mar 14 18:20:52 2012
Raid Level : raid10
Array Size : 3662760640 (3493.08 GiB 3750.67 GB)
Used Dev Size : 1465104256 (1397.23 GiB 1500.27 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 2
Persistence : Superblock is persistent
Кажется, это противоречит этому. (то же самое для каждого диска в массиве)
mdadm --examine /dev/sdc2
/dev/sdc2:
Magic : a92b4efc
Version : 0.90.00
UUID : 1f54d708:60227dd6:163c2a05:89fa2e07 (local to host)
Creation Time : Wed Mar 14 18:20:52 2012
Raid Level : raid10
Used Dev Size : 1465104320 (1397.23 GiB 1500.27 GB)
Array Size : 2930208640 (2794.46 GiB 3000.53 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 2
Массив создавался вот так.
mdadm -v --create /dev/md2 \
--level=raid10 --layout=o2 --raid-devices=5 \
--chunk=64 --metadata=0.90 \
/dev/sdg2 /dev/sdf2 /dev/sde2 /dev/sdd2 /dev/sdc2
У каждого из 5 отдельных дисков есть такие разделы.
Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00057754
Device Boot Start End Blocks Id System
/dev/sdc1 2048 34815 16384 83 Linux
/dev/sdc2 34816 2930243583 1465104384 fd Linux raid autodetect
Предыстория
Итак, контроллер SATA вышел из строя в коробке, которую я поддерживаю. Сбой был ужасным, поэтому отдельные диски постепенно выпадали из массива. Хотя есть резервные копии, на самом деле мы делаем их не так часто, как нам действительно нужно. Есть некоторые данные, которые я пытаюсь восстановить, если смогу.
Я получил дополнительное оборудование и снова смог получить доступ к дискам. С дисками все в порядке, и я могу активировать и смонтировать массив и файловую систему (в режиме только для чтения). Я могу получить доступ к некоторым данным в файловой системе и копировал их, но я вижу много ошибок, когда пытаюсь скопировать самые последние данные.
Когда я пытаюсь получить доступ к этим самым последним данным, я получаю такие ошибки, как показано ниже, что заставляет меня думать, что несоответствие размера массива может быть проблемой.
Mar 14 18:26:04 server kernel: [351588.196299] dm-7: rw=0, want=6619839616, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.196309] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.196313] dm-7: rw=0, want=6619839616, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.199260] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.199264] dm-7: rw=0, want=20647626304, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.202446] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.202450] dm-7: rw=0, want=19973212288, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.205516] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.205520] dm-7: rw=0, want=8009695096, limit=6442450944
Если вы можете клонировать диски с помощью dd, я бы это сделал. Сохраняйте оригинальные диски как можно более нетронутыми.
Тогда это полный выстрел от бедра, но это то, что я бы попробовал, будь я в такой ситуации. С клонированными дисками в системе я бы стер все метаданные RAID, используя.
mdadm --zero-superblock /dev/sdx#
на каждом из задействованных дисков.
Затем используйте команду для воссоздания массива.
mdadm -v --create /dev/md2 \
--level=raid10 --layout=o2 --raid-devices=5 \
--chunk=64 --metadata=0.90 --assume-clean \
/dev/sdg2 /dev/sdf2 /dev/sde2 /dev/sdd2 /dev/sdc2
Это должно избавить от всех проблем с уровнем рейда. Оттуда вы можете попробовать перемонтировать файловые системы и посмотреть, что осталось. А если это не сработает, повторно клонируйте диски и попробуйте что-нибудь еще :)
Вы уверены в своей командной строке для создания массива? Я предполагаю, что это был "стандартный" массив raid10 из 4 дисков с диском горячего резерва, что объясняет результат / dev / sdc2
Можете ли вы рассказать нам результат:
cat /proc/mdstat
cat /etc/mdadm.conf
mdadm --examine /dev/sdx2 ( each drive )
С его помощью вы сможете угадать, какой из дисков был горячим резервом, и таким образом сможете правильно восстановить массив. Конечно, как заявляет 3dinfluence, вам следует продублировать данные, прежде чем пытаться перенастроить массив.
Изменить: также, вероятно, это не пустая трата времени для запуска: smartctl -a /dev/sdx на каждом диске (проверьте в конце вывода, были ли сообщения об ошибках), а затем smartcl -t long /dev/sdx и через 3 или 4 часа снова smartctl -a, чтобы проверить, что 5 дисков действительно хорошо. Если один диск сообщает об ошибках, возможно, он был обнаружен mdadm как неисправный, и поэтому mdadm включил запасной диск (всегда предположение)
Редактировать 2: если vgs сообщает: vgdisplay показывает Alloc PE / Size 3.00 TiB, Free PE / Size 421.08 Это означает, что ваш PV загадочным образом вырос до 421G .. Я верю в свой случай: "загадочный" рост - это неправильная конфигурация вашего массива . Реальный размер вашего массива - 3Т. Вы неправильно его собрали, поэтому он поврежден. Чтобы правильно собрать его, вам нужно получить исходную конфигурацию и какой из дисков был запасным. Удачи.