FreeBSD: Remover links simbólicos no devfs

3

Antecedentes

Eu tenho reconstruído um NAS de pequena casa. Este servidor representa minha primeira incursão 'real' no mundo da administração de servidores e já me ensinou bastante. Originalmente, a coisa foi configurada usando o FreeNAS em um pen drive com 3 discos magnéticos configurados em um raidz1. Desde então resolvi migrar todo o sistema para o FreeBSD 9.0 (STABLE) para um maior controle do sistema, além de simplesmente aprender como "fazer sozinho". Tudo está indo bem, com o sistema operacional instalado e atualizado com sucesso (pen drive novamente, rw, com tempos de acesso e algumas outras coisas desabilitadas para evitar abuso de flash).

Agora estou trabalhando na configuração do meu armazenamento em disco magnético, novamente usando um raidz1. Para este fim, eu copiei todos os arquivos que eu quero persistir para o armazenamento externo. Ao explorar os vários comandos do zfs, descobri que o zpool original da instalação do FreeNAS ainda estava visível. Eu importei e atualizei o pool usando

# zpool import ZFS1 tank   //Import the original zpool 'ZFS1', renaming it 'tank'
# zpool upgrade tank       //FreeNAS uses an older ZFS version, FreeBDS is v28
# zfs mount tank

e conseguiu ver meus arquivos novamente. Molho Depois de bisbilhotar um pouco, decidi que ainda queria soprar a velha piscina e começar de novo. Eu emiti

# zfs umount tank
# zpool destroy tank

que foi concluído sem erro. Agora estou procurando recriar um raidz1 'limpo' com esses discos.

Pergunta

Antes de criar o novo raidz1, fiz algumas pesquisas em /dev , apenas para ver o que poderia aprender. Eu queria examinar os discos magnéticos que foram usados na matriz, mas a saída que recebi parece estranha para mim. Pior, googling não explica realmente o que está acontecendo. Os discos estão listados da seguinte forma:

# ls -l ad*
lrwxr-xr-x  1 root  wheel            4 Aug 12 20:50 ad2 -> ada2
lrwxr-xr-x  1 root  wheel            4 Aug 12 20:50 ad4 -> ada0
lrwxr-xr-x  1 root  wheel            4 Aug 12 20:50 ad6 -> ada1
crw-r-----  1 root  operator    0,  96 Aug 12 20:50 ada0
crw-r-----  1 root  operator    0,  98 Aug 12 20:50 ada1
crw-r-----  1 root  operator    0, 100 Aug 12 20:50 ada2

Eu sei que criei três discos virtuais no FreeNAS enquanto configurava o ataque, que é onde eu suspeito que os links vieram. Minhas perguntas sobre isso são as seguintes:

  1. Pesquisando como os links simbólicos funcionam, entendo que um link simbólico é apenas um arquivo que vincula um item a outro. Se esse for o caso, por que os dispositivos ada * listados com o atributo 'l' e os dispositivos de hardware reais listados com outro atributo (talvez dispositivo de bloco)?

  2. Esses links são um artefato da configuração anterior que não são considerados necessários. Eles podem ser excluídos? Se sim, como (meio que com medo de ir removendo as coisas querendo ou não; veja o último link na seção de referências)? A exclusão das entradas ad* removerá implicitamente os ada* nós, já que agora eles se referem a um link que não existe? Ou eu tenho isso de trás para frente?

  3. Quais são os dispositivos de hardware reais? Como mencionei na minha pergunta anterior, eu acho que os ad* nós seriam um dispositivo de caractere ou algo semelhante e os ada* nós seriam os arquivos de link.

  4. Finalmente, sei que definitivamente há alguma variação baseada na configuração e nas preferências individuais, mas qual é a maneira 'aceita' de configurar meus dispositivos SATA para um simples raidz1? Todo esse negócio de links simbólicos parece um exagero para um simples NAS doméstico.

Minhas desculpas pelo longo post, mas eu tenho tentado por algum tempo para entender isso. Agradecemos antecipadamente pelo seu tempo e assistência.

Referências

por phobos51594 16.08.2012 / 19:18

1 resposta

2
  1. ada dispositivos são unidades conectadas a portas SATA mais novas. Algumas pessoas perderam o memorando para que o DevFS fosse modificado para fornecer links simbólicos para esses nomes de dispositivos como os dispositivos ad tradicionais. No entanto, o sistema provavelmente já possui algumas portas SATA mais antigas ou portas IDE, de modo que elas ocuparão os números de dispositivos ad mais baixos (ad0, ad1, etc). Portanto, os ada deviecs mapeados obtêm números mais altos.

    Nota: Se você ainda não percebeu, /dev é um tipo diferente de sistema de arquivos ( devfs ). Embora ele mostre construções simples como links simbólicos, elas não são links simbólicos reais no sentido em que você está pensando.

  2. Sua premissa está errada, veja # 1.
  3. Os que não dizem que são links simbólicos (via l como você observou) são drivers de dispositivo. O quão "real" elas são varia, pois o software também pode fornecer um dispositivo.
  4. Eu considero que a "melhor" maneira é usar partições GPT, dar-lhes nomes sensatos e incluir as partições nomeadas como vdevs para o raidz.

    Algo como o seguinte faria isso:

    gpart create -s GPT ada0
    gpart create -s GPT ada1
    gpart create -s GPT ada2
    
    gpart add -t freebsd-zfs -l tank-disk0 ada0
    gpart add -t freebsd-zfs -l tank-disk1 ada1
    gpart add -t freebsd-zfs -l tank-disk2 ada2
    
    zpool create tank raidz /dev/gpt/tank-disk0 /dev/gpt/tank-disk1 /dev/gpt/tank-disk2
    

    Caso contrário, passar os discos diretamente para o ZFS seria o mais recomendado. Existem proponentes de ambas as configurações. Se você seguir esse caminho, sugiro também configurar o smartd para monitorar a integridade do disco. Além disso, configure periodic para limpar o zpool, monitorar o SMART e enviar relatórios periódicos (semanalmente ou o que você preferir).

Em uma nota lateral, o FreeNAS e os outros projetos derivados do FreeBSD tornam o uso do FreeBSD muito mais fácil do que simplesmente mergulhar no sistema operacional central. O Manual o guiará pela grande maioria do que você deseja configurar , mas você vai se deparar com as coisas ao longo do tempo também. Se você for "manual" do Google, o Manual do FreeBSD é o link número 2; é tão importante / popular / bom.

Uma outra nota sobre as referências. O primeiro é um mau exemplo, já que você não deveria ligar simbolicamente as placas de rede, você deve renomeá-las (não uma renomeação de tipo de sistema de arquivos). O DevFS responde às solicitações de vinculação e desconexão, principalmente conforme o esperado. A segunda e terceira referências parecem muito boas. Tenha em mente que existem mais tipos de links do que links simbólicos.

    
por 16.08.2012 / 19:37