Eu tive o mesmo problema, eu não tenho certeza, mas o trabalho que eu encontrei foi criar novas partições nos membros raid do tipo LINUX Raid e então ao criar o array eu usei a partição ao invés de usar o dispositivo. / p>
A matriz RAID não é montada após a reinicialização.
Eu tenho um SSD do qual o sistema é inicializado e três HDD que fazem parte do array. O sistema é o Ubuntu 16.04.
Os passos que segui baseiam-se principalmente neste guia:
Verificando se estou pronto para ir.
lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
A saída mostra dispositivos sda, sdb e sdc além das partições SSD. Eu verifiquei se eles de fato representam os HDDs olhando para a saída disso:
hwinfo --disk
Tudo corresponde.
Montando a matriz.
sudo mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sda /dev/sdb /dev/sdc
Verifico se está tudo bem digitando: cat / proc / mdstat
A saída é algo como isto:
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdc[3] sdb[1] sda[0]
7813774336 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=======>.............] recovery = 37.1% (1449842680/3906887168) finish=273.8min speed=149549K/sec
bitmap: 0/30 pages [0KB], 65536KB chunk
unused devices: <none>
Espero até o fim do processo.
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdc[3] sdb[1] sda[0]
209584128 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Criando e montando o sistema de arquivos.
sudo mkfs.ext4 -F /dev/md0
sudo mkdir -p /mnt/md0
sudo mount /dev/md0 /mnt/md0
df -h -x devtmpfs -x tmpfs
Eu coloco alguns dados, e a saída é assim:
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p2 406G 191G 196G 50% /
/dev/nvme0n1p1 511M 3.6M 508M 1% /boot/efi
/dev/md0 7.3T 904G 6.0T 13% /mnt/md0
Salvando o layout da matriz.
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
sudo update-initramfs -u
echo '/dev/md0 /mnt/md0 ext4 defaults,nofail,discard 0 0' | sudo tee -a /etc/fstab
Reiniciando e verificando se tudo funciona corretamente.
Após a reinicialização, tento:
gato / proc / mdstat
Não está mostrando nenhum dispositivo de ataque ativo.
ls /mnt/md0
está vazio.
O comando a seguir não imprime nada e não funciona:
mdadm --assemble --scan -v
Somente o seguinte restaura a matriz com dados:
sudo mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sda /dev/sdb /dev/sdc
O que deve ser feito de maneira diferente?
Informações adicionais, provavelmente úteis:
sudo dpkg-reconfigure mdadm
A saída mostra:
update-initramfs: deferring update (trigger activated)
Generating grub configuration file ...
Warning: Setting GRUB_TIMEOUT to a non-zero value when GRUB_HIDDEN_TIMEOUT is set is no longer supported.
Found linux image: /boot/vmlinuz-4.4.0-51-generic
Found initrd image: /boot/initrd.img-4.4.0-51-generic
Found linux image: /boot/vmlinuz-4.4.0-31-generic
Found initrd image: /boot/initrd.img-4.4.0-31-generic
Adding boot menu entry for EFI firmware configuration
done
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Processing triggers for initramfs-tools (0.122ubuntu8.5) ...
update-initramfs: Generating /boot/initrd.img-4.4.0-51-generic
A parte intrigante para mim é "ações de início e parada não são mais suportadas; voltando aos padrões"
Além disso, a saída de / usr / share / mdadm / mkconf não imprime quaisquer matrizes no final.
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR [email protected]
# definitions of existing MD arrays
considerando que a saída de cat /etc/mdadm/mdadm.conf faz.
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers
# DEVICE /dev/sda /dev/sdb /dev/sdc
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR [email protected]
# definitions of existing MD arrays
# This file was auto-generated on Sun, 04 Dec 2016 18:56:42 +0100
# by mkconf $Id$
ARRAY /dev/md0 metadata=1.2 spares=1 name=hinton:0 UUID=616991f1:dc03795b:8d09b1d4:8393060a
Qual é a solução? Eu naveguei pela metade da internet e ninguém parece ter o mesmo problema.
Eu também adicionei exatamente a mesma pergunta no serverfault há alguns dias (sem resposta). Peço desculpas se violei as regras da comunidade de troca de pilha fazendo isso.
Eu tive o mesmo problema, eu não tenho certeza, mas o trabalho que eu encontrei foi criar novas partições nos membros raid do tipo LINUX Raid e então ao criar o array eu usei a partição ao invés de usar o dispositivo. / p>
Não consegui reproduzir o seu problema exato, mas acho que encontrei uma possível razão para o comportamento do seu sistema:
Quando você cria a matriz RAID5 de 3 discos com o comando:
sudo mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sda /dev/sdb /dev/sdc
Enquanto o dispositivo RAID está em recuperação, o comando mdadm scan mostra:
sudo mdadm --detail --scan
ARRAY /dev/md0 metadata=1.2 spares=1 name=desktop:0 UUID=da60c69a:1cbe4f2e:e83d0971:0520ac89
Após a conclusão do processo de recuperação, o parâmetro spares=1 desaparece:
sudo mdadm --detail --scan
ARRAY /dev/md0 metadata=1.2 name=desktop:0 UUID=da60c69a:1cbe4f2e:e83d0971:0520ac89
Suponho que a recomposição da leitura de 3 discos com o parâmetro spares=1 falhe em um software RAID5 totalmente recuperado, já que você não tem mais discos preservados. Se você tentar montar um RAID com o seguinte comando, ele falhará:
sudo mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 --spare-devices=1 /dev/sda /dev/sdb /dev/sdc
e o próximo comando criará um layout RAID diferente:
sudo mdadm --create --verbose /dev/md0 --level=5 --raid-devices=2 --spare-devices=1 /dev/sda /dev/sdb /dev/sdc
Em uma nota diferente: se você não precisar inicializar a partir do RAID5, não será necessário adicionar a configuração ao arquivo /etc/mdadm/mdadm.conf . O Ubuntu iniciará automaticamente o RAID, já que a configuração está disponível no superbloco RAID.
Tags raid