У меня есть сервер с CentOS 7, использующий LUN для хранения данных . Недавно группа Storage расширила пространство LUN. Это результат команды multipath -ll
~ # multipath -ll
mpathc (3600601606cb04000a0eb35b80750eb11) dm-5 DGC ,VRAID
**size=27T** features='2 queue_if_no_path retain_attached_hw_handler' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 1:0:0:2 sdl 8:176 active ready running
| `- 4:0:0:2 sdn 8:208 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
|- 1:0:1:2 sdm 8:192 active ready running
`- 4:0:2:2 sdo 8:224 active ready running
. Предыдущий размер был 20 ТБ, а теперь увеличился до 27 ТБ.
Это результат команды fdisk
fdisk -l /dev/mapper/mpathc
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
Disk /dev/mapper/mpathc: 29686.8 GB, 29686813949952 bytes, 57982058496 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 4194304 bytes
Disk label type: gpt
Disk identifier: 843A6F7E-581A-455E-822F-2CE4306394BF
# Start End Size Type Name
1 8192 42949672926 20T Linux filesyste
. Вы можете видеть, что размер и количество секторов LUN увеличены. Это результат команды kpartx
kpartx -l /dev/mapper/mpathc
GPT:Primary header thinks Alt. header is not at the end of the disk.
GPT:Alternate GPT header not at the end of the disk.
GPT: Use GNU Parted to correct GPT errors.
mpathc1 : 0 42949664735 /dev/mapper/mpathc 8192
и результат команды df
df -h /dev/mapper/mpathc1
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/mpathc1 20T 17T 4.0T 81% /Splunk-Storage/COLD
Поэтому я не могу понять, как я могу расширить пространство / dev / mapper / mpathc1 без потери данных. Я очень благодарен за любое предложение Заранее спасибо
Шаг 1 : Попробуйте повторно просканировать устройства хранения, чтобы сообщить ядру об изменении размера. Я не уверен, нужно ли это делать для всех четырех компонентов многолучевого распространения, но это не должно повредить. Вы повторно сканируете устройства хранения, записывая что-нибудь в их файл rescan
:
echo > /sys/class/block/sdl/device/rescan
echo > /sys/class/block/sdm/device/rescan
echo > /sys/class/block/sdn/device/rescan
echo > /sys/class/block/sdo/device/rescan
Сканирование HBA также должно работать. SCSI HBA имеют файл сканирования
; вы записываете в него три десятичных числа: контроллер, цель и LUN для сканирования этого LUN. Или используйте подстановочный знак «-» вместо числа. Следующее выполняет сканирование всех устройств на контроллере 0 на двух HBA:
echo "0 - -" > /sys/class/scsi_host/host1/scan
echo "0 - -" > /sys/class/scsi_host/host4/scan
Шаг 2 : На этом этапе ядру известно, что размер / dev / mapper / mpathc
составляет 27 ТБ. Теперь вам нужно увеличить размер раздела 1. Для изменения размера разделов можно использовать команду parted
, но я считаю, что версия parted
для Centos 7 не имеет такой возможности.Поэтому я бы размонтировал файловую систему, удалил раздел (страшно, я знаю), а затем снова создал раздел, на этот раз с правильным размером. Убедитесь, что его параметры верны.
umount /dev/mapper/mpathc1
parted /dev/mapper/mpathc1 rm 1 mkpart primary 0% 100% print
Вы можете сначала протестировать это на диске, который не содержит ценных данных.
Я не знаю, можно ли установить parted
версию, в которой есть команда resizepart
. Так будет легче сделать второй шаг.
Руководство по хранению RHEL 7 содержит аналогичную процедуру с fdisk
, но предполагает использование LVM и отсутствие многопутевости. После процедуры fdisk
вам, вероятно, придется использовать kpartx
, чтобы сообщить ядру об изменениях на диске. Таким образом, раздельный подход кажется мне проще, а значит, безопаснее.
Шаг 3 : Увеличьте файловую систему. Сначала снова установите его. Если это XFS, вы должны смонтировать его, а затем запустить xfs_growfs
.
mount /dev/mapper/mpathc1 /Splunk-Storage/COLD
xfs_growfs /Splunk-Storage/COLD
Если это ext [234], запустите resize2fs
. Он может быть установлен или демонтирован.
resize2fs /dev/mapper/mpathc1
mount /dev/mapper/mpathc1 /Splunk-Storage/COLD
Готово.
Спасибо за ваше время.
В шаге 2 я использовал resizepart
, но получил следующее:
Ошибка: Резервная таблица GPT не находится в конце диска, как это должно быть. Это может означать, что другая операционная система считает, что диск меньше. Исправить, переместив резервную копию в конец (и удалив старую резервную копию)? Исправить/Игнорировать/Отменить?
Стоит ли исправлять?
Вот полный результат
~ # parted /dev/mapper/mpathc
GNU Parted 3.1
Using /dev/mapper/mpathc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the
disk is smaller. Fix, by moving the backup to the end (and removing the old backup)?
Fix/Ignore/Cancel? I
Warning: Not all of the space available to /dev/mapper/mpathc appears to be used, you can fix the GPT to use all of the space (an extra
15032385536 blocks) or continue with the current setting?
Fix/Ignore? I
Model: Linux device-mapper (multipath) (dm)
Disk /dev/mapper/mpathc: 29.7TB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 4194kB 22.0TB 22.0TB xfs
(parted) resizepart
Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the
disk is smaller. Fix, by moving the backup to the end (and removing the old backup)?
Fix/Ignore/Cancel? C