A unidade de troca a quente recebeu um novo nome. Se eu o adicionar novamente ao array `md` e ele for renomeado na reinicialização, o array ainda funcionará?

Um dos HDDs na configuração RAID do meu servidor falhou, então eu o tirei da matriz e fiz com que o data center o trocasse a quente. Eles fizeram isso, mas agora a nova unidade é /dev/sdcmelhor que /dev/sda. Suspeito que, se eu reiniciar o servidor, ele será /dev/sdanovamente, por isso hesito em adicioná-lo novamente à matriz, /dev/sdcporque não quero criar uma armadilha para que eu caia na próxima reinicialização. Eu não reiniciaria o servidor se não precisasse (se precisar, bem, que pena).

Se eu adicionar como /dev/sdc, haverá um problema na reinicialização? Ou existe alguma maneira de alterar o nome do dispositivo de /dev/sdcpara /dev/sdasem reiniciar?

Isso está no Ubuntu 10.04 LTS. É uma mdmatriz ("Linux Software RAID"), onde atualmente um dos dispositivos (existem alguns) se parece com isso ("degradado" porque removi o antigo /dev/sda):

# mdadm --detail / dev / md0
/ dev / md0:
        Versão: 00.90.03
  Hora da criação: Dom Out 11 21:07:54 2009
     Nível da raide: raid1
     Tamanho da matriz: 97536 (95,27 MiB 99,88 MB)
  Tamanho do desenvolvedor usado: 97536 (95,27 MiB 99,88 MB)
   Dispositivos de invasão: 2
  Total de dispositivos: 1
Menor preferido: 0
    Persistência: o superbloco é persistente

    Hora da atualização: Qui. 30 de junho 09:31:16 2011
          Estado: limpo, degradado
 Dispositivos ativos: 1
Dispositivos de trabalho: 1
 Dispositivos com falha: 0
  Dispositivos Sobressalentes: 0

           UUID: 496be7a5: ab9177ed: 7792c71e: 7dc17aa4
         Eventos: 0.112

    Número principal de incursões menores
       0 8 17 0 sync ativo / dev / sdb1
       1 0 0 1 removido

ubuntu hard-drive hotswap

— TJ Crowder
fonte

Qual matriz? Se é UIDs digitalização não importa se é sda ou SDC

— Jure1873

É uma mdmatriz ("Linux Software RAID"). Toda a adição / remoção de dispositivos refere-se a nomes de dispositivos, mas eu não sei o que significa que realmente depende deles ou ... Eu adicionei a saída mdadm --detaildele à pergunta.

— TJ Crowder

para md arrays, o mdadm varre todos os discos (conforme definido em /etc/mdadm.conf), portanto, não importa onde eles estejam, porque grava um ID no cabeçalho do disco para poder remontar as matrizes.

— precisa saber é o seguinte

Sim, obrigado, confira a atualização sobre a questão, descrevi esse comportamento e verifiquei duas vezes.

— TJ Crowder

@TJCrowder, em vez (ou além disso) de atualizar sua pergunta, você pode adicionar sua descoberta como resposta (e aceitá-la), pois essa questão é basicamente resolvida.

— Dennis Nolte

É bom ir em frente e adicioná-lo como /dev/sdc. Lendo a mddocumentação do kernel , se o nome mudar na reinicialização, não importa. (Bom design, isso.) Eis o porquê:

Detecção automática no tempo de inicialização de matrizes RAID

Quando o md é compilado no kernel (não como módulo), as partições do tipo 0xfd são varridas e montadas automaticamente nas matrizes RAID. Essa detecção automática pode ser suprimida com o parâmetro do kernel "raid = noautodetect". A partir do kernel 2.6.9, somente unidades com um superbloco do tipo 0 podem ser detectadas automaticamente e executadas no momento da inicialização.

O parâmetro do kernel "raid = particionável" (ou "raid = parte") significa que todas as matrizes detectadas automaticamente são montadas como particionáveis.

Embora eu não tenha mdcompilado no kernel, minha instalação faz a mesma coisa que a anterior, porque é carregada automaticamente mdadme mdadm.confestá configurada para verificar todas as partições em busca de um superbloco, como faria o kernel:

# por padrão, verifique todas as partições (/ proc / partitions) em busca de superblocos de MD.
# alternativamente, especifique os dispositivos a serem verificados, usando curingas, se desejar.
Partições DEVICE

Portanto, é bom reconstruir a matriz com /dev/sdc; o nome provavelmente mudará para /dev/sdana reinicialização, mas isso não causará problemas se mdestiver configurado como acima.

— TJ Crowder
fonte