                         O Gerenciador de Volume vinum

  Greg Lehey

   Escrito originalmente por  
   [ Documento HTML em partes / Documento HTML completo ]

     ----------------------------------------------------------------------

   Indice

   1. Sinopse

   2. Gargalos de Acesso

   3. Integridade de dados

   4. Objetos do vinum

   5. Alguns exemplos

   6. Nomeac,ao de Objetos

   7. Configurando o vinum

   8. Usando o vinum para o sistema de arquivos raiz

1. Sinopse

   Nao importa o tipo de disco, sempre ha problemas em potencial. Os discos
   podem ser muito pequenos, muito lentos ou pouco confiaveis para atender
   aos requisitos do sistema. Enquanto os discos estao ficando maiores,
   tambem ficam maiores os requisitos para armazenamento de dados.
   Geralmente, e necessario um sistema de arquivos maior que a capacidade de
   um disco. Varias soluc,oes para esses problemas foram propostas e
   implementadas.

   Um metodo e atraves do uso de varios discos, e `as vezes discos
   redundantes. Alem de suportar varias placas e controladoras para sistemas
   RAID (Redundant Array of Independent Disks), o sistema basico do FreeBSD
   inclui o gerenciador de volumes vinum, um driver de dispositivo de bloco
   que implementa discos virtuais e aborda esses tres problemas. O vinum
   oferece mais flexibilidade, desempenho e confiabilidade do que o
   armazenamento em disco tradicional e implementa os modelos RAID-0, RAID-1
   e RAID-5, tanto individualmente quanto combinados.

   Este capitulo fornece uma visao geral dos possiveis problemas com o
   armazenamento em disco tradicional e uma introduc,ao ao gerenciador de
   volumes vinum.

  Nota:

   Comec,ando com o FreeBSD 5, o vinum foi reescrito para se encaixar na
   Arquitetura GEOM, mantendo as ideias originais, a terminologia e os
   metadados no disco. Esta reescrita e chamada gvinum (para GEOM vinum).
   Enquanto este capitulo usa o termo vinum, qualquer invocac,ao de comandos
   deve ser executada com o gvinum. O nome do modulo do kernel mudou do
   original vinum.ko para geom_vinum.ko, e todos os device nodes residem em
   /dev/gvinum em vez de /dev/vinum. A partir do FreeBSD 6, a implementac,ao
   original do vinum nao esta mais disponivel no codigo base.

2. Gargalos de Acesso

   Sistemas modernos frequentemente precisam acessar dados de uma maneira
   altamente concorrente. Por exemplo, grandes servidores FTP ou HTTP podem
   manter milhares de sessoes simultaneas e ter multiplas conexoes de 100
   Mbit/s para o mundo externo, muito alem da taxa de transferencia
   sustentada da maioria dos discos.

   As unidades de disco atuais podem transferir dados sequencialmente a ate
   70 MB/s, mas esse valor e de pouca importancia em um ambiente em que
   muitos processos independentes acessam uma unidade e onde podem obter
   apenas uma frac,ao desses valores. Nesses casos, e mais interessante
   visualizar o problema do ponto de vista do subsistema de disco. O
   parametro importante e a carga que uma transferencia coloca no subsistema
   ou o tempo pelo qual uma transferencia ocupa as unidades envolvidas na
   transferencia.

   Em qualquer transferencia de disco, a unidade deve primeiro posicionar as
   cabec,as, aguardar que o primeiro setor passe sob a cabec,a de leitura e
   depois realizar a transferencia. Essas ac,oes podem ser consideradas
   atomicas, pois nao faz sentido interrompe-las.

   Considere uma transferencia tipica de cerca de 10 kB: a gerac,ao atual de
   discos de alto desempenho pode posicionar as cabec,as em uma media de 3,5
   ms. As unidades mais rapidas giram a 15.000 rpm, portanto a latencia
   rotacional media (meia revoluc,ao) e de 2 ms. A 70 MB/s, a propria
   transferencia leva cerca de 150 ms, quase nada em comparac,ao com o tempo
   de posicionamento. Nesse caso, a taxa de transferencia efetiva cai para
   pouco mais de 1 MB/s e e claramente altamente dependente do tamanho da
   transferencia.

   A soluc,ao tradicional e obvia para esse gargalo e "mais eixos": em vez de
   usar um disco grande, use varios discos menores com o mesmo espac,o de
   armazenamento agregado. Cada disco e capaz de se posicionar e transferir
   de forma independente, portanto, o rendimento efetivo aumenta em um fator
   proximo ao numero de discos usados.

   A melhoria real da taxa de transferencia e menor que o numero de discos
   envolvidos. Embora cada unidade seja capaz de transferir em paralelo, nao
   ha como garantir que as solicitac,oes sejam distribuidas uniformemente
   pelas unidades. Inevitavelmente, a carga em uma unidade sera maior que em
   outra.

   A uniformidade da carga nos discos e fortemente dependente da maneira como
   os dados sao compartilhados entre as unidades. Na discussao a seguir, e
   conveniente pensar no armazenamento em disco como um grande numero de
   setores de dados que sao enderec,aveis por numero, mais ou menos como as
   paginas de um livro. O metodo mais obvio e dividir o disco virtual em
   grupos de setores consecutivos do tamanho dos discos fisicos individuais e
   armazena-los dessa maneira, mais ou menos como pegar um livro grande e
   dividi-lo em sec,oes menores. Esse metodo e chamado de concatenac,ao e tem
   a vantagem de os discos nao precisarem ter nenhum relacionamento de
   tamanho especifico. Ele funciona bem quando o acesso ao disco virtual e
   distribuido uniformemente sobre seu espac,o de enderec,o. Quando o acesso
   e concentrado em uma area menor, a melhoria e menos acentuada. Figura 1,
   "Organizac,ao Concatenada" ilustra a sequ:encia na qual as unidades de
   armazenamento sao alocadas em uma organizac,ao concatenada.

   Figura 1. Organizac,ao Concatenada
   Organizac,ao Concatenada

   Um mapeamento alternativo e dividir o espac,o de enderec,o em componentes
   menores e de tamanhos iguais e armazena-los sequencialmente em diferentes
   dispositivos. Por exemplo, os primeiros 256 setores podem ser armazenados
   no primeiro disco, os proximos 256 setores no proximo disco e assim por
   diante. Depois de preencher o ultimo disco, o processo e repetido ate que
   os discos estejam cheios. Este mapeamento e chamado striping ou RAID-0.

   O RAID oferece varias formas de tolerancia a falhas, embora o RAID-0 seja
   um pouco enganador, pois nao fornece redundancia. O striping requer um
   pouco mais de esforc,o para localizar os dados e pode causar carga de I/O
   (INPUT/OUTPUT) adicional, onde uma transferencia e distribuida por varios
   discos, mas tambem pode fornecer uma carga mais constante nos discos.
   Figura 2, "Organizac,ao do modo distribuido (Striped)" ilustra a
   sequ:encia na qual as unidades de armazenamento sao alocadas em uma
   organizac,ao distribuida.

   Figura 2. Organizac,ao do modo distribuido (Striped)
   Organizac,ao do modo distribuido (Striped)

3. Integridade de dados

   O problema final com os discos e que eles nao sao confiaveis. Embora a
   confiabilidade tenha aumentado tremendamente nos ultimos anos, as unidades
   de disco ainda sao o componente central mais provavel de um servidor para
   falhar. Quando o fazem, os resultados podem ser catastroficos e substituir
   uma unidade de disco com falha e a restaurac,ao de dados pode resultar em
   tempo de inatividade do servidor.

   Uma abordagem para esse problema e o mirroring (espelhamento), ou RAID-1,
   que mantem duas copias dos dados em diferentes hardwares fisicos. Qualquer
   gravac,ao no volume grava em ambos os discos; uma leitura pode ser
   satisfeita de qualquer um, portanto, se uma unidade falhar, os dados ainda
   estarao disponiveis na outra unidade.

   O mirroring tem dois problemas:

     * Requer o dobro de armazenamento em disco que uma soluc,ao nao
       redundante.

     * As gravac,oes devem ser executadas em ambas as unidades, entao ela usa
       o dobro da largura de banda de um volume nao espelhado. As leituras
       nao sofrem uma penalidade de desempenho e podem ate ser mais rapidas.

   Uma soluc,ao alternativa e a parity (paridade), implementada nos niveis
   RAID 2, 3, 4 e 5. Destes, o RAID-5 e o mais interessante. Como
   implementado no vinum, e uma variante em uma organizac,ao striped que
   dedica um bloco de cada distribuic,ao `a paridade de um dos outros blocos.
   Como implementado por vinum, um plex RAID-5 e semelhante a um plex
   striped, exceto que ele implementa RAID-5 incluindo um bloco de paridade
   em cada stripe. Conforme exigido pelo RAID-5, o local desse bloco de
   paridade muda de um stripe para o proximo. Os numeros nos blocos de dados
   indicam os numeros de blocos relativos.

   Figura 3. Organizac,ao RAID-5
   Organizac,ao RAID-5

   Comparado ao mirroring, o RAID-5 tem a vantagem de exigir
   significativamente menos espac,o de armazenamento. O acesso de leitura e
   semelhante ao das organizac,oes distribuidas, mas o acesso de gravac,ao e
   significativamente mais lento, aproximadamente 25% do desempenho de
   leitura. Se uma unidade falhar, a matriz pode continuar a operar no modo
   degradado, onde uma leitura de uma das unidades acessiveis restantes
   continua normalmente, mas uma leitura da unidade com falha e recalculada a
   partir do bloco correspondente de todas as unidades restantes.

4. Objetos do vinum

   A fim de resolver estes problemas, o vinum implementa uma hierarquia de
   quatro niveis de objetos:

     * O objeto mais visivel e o disco virtual, chamado volume. Os volumes
       tem essencialmente as mesmas propriedades de uma unidade de disco
       UNIX(R), embora haja algumas pequenas diferenc,as. Por um lado, eles
       nao tem limitac,oes de tamanho.

     * Os volumes sao compostos de plexes, cada um dos quais representa o
       espac,o de enderec,o total de um volume. Este nivel na hierarquia
       fornece redundancia. Pense em plexes como discos individuais em uma
       matriz espelhada, cada um contendo os mesmos dados.

     * Como o vinum existe dentro do framework de armazenamento em disco
       UNIX(R), seria possivel usar as partic,oes UNIX(R) como bloco de
       construc,ao para plexes de varios discos. Na verdade, isso acaba sendo
       muito inflexivel, pois os discos UNIX(R) podem ter apenas um numero
       limitado de partic,oes. Em vez disso, o vinum subdivide uma unica
       partic,ao UNIX(R), a unidade, em areas contiguas chamadas subdiscos ,
       que sao usados como blocos de construc,ao para plexes.

     * Subdiscos residem em vinum drives, atualmente partic,oes UNIX(R).
       Unidades vinum podem conter qualquer numero de subdiscos. Com excec,ao
       de uma pequena area no inicio da unidade, que e usada para armazenar
       informac,oes de configurac,ao e estado, a unidade inteira esta
       disponivel para armazenamento de dados.

   As sec,oes a seguir descrevem a maneira como esses objetos fornecem a
   funcionalidade necessaria do vinum.

  4.1. Considerac,oes sobre o tamanho do volume

   Os plexes podem incluir varios subdiscos distribuidos por todas as
   unidades na configurac,ao vinum. Como resultado, o tamanho de uma unidade
   individual nao limita o tamanho de um plex ou de um volume.

  4.2. Armazenamento de Dados Redundantes

   O vinum implementa o espelhamento anexando varios plexes a um volume. Cada
   plex e uma representac,ao dos dados em um volume. Um volume pode conter
   entre um e oito plexes.

   Embora um plex represente os dados completos de um volume, e possivel que
   partes da representac,ao estejam fisicamente ausentes, seja por design
   (por nao definir um subdisco para partes do plex) ou por acidente (como
   resultado da falha de representac,ao). Contanto que pelo menos um plex
   possa fornecer os dados para o intervalo de enderec,os completo do volume,
   o volume estara totalmente funcional.

  4.3. Quais sao as organizac,oes disponiveis para um Plex?

   O vinum implementa a concatenac,ao e o striping no nivel plex:

     * Um plex concatenado usa o espac,o de enderec,o de cada subdisco um de
       cada vez. Plexes concatenados sao os mais flexiveis, pois podem conter
       qualquer numero de subdiscos e os subdiscos podem ser de tamanho
       diferente. O plex pode ser estendido adicionando subdiscos adicionais.
       Eles exigem menos tempo de CPU do que os plexes distribuidos, embora a
       diferenc,a na sobrecarga de CPU nao seja mensuravel. Por outro lado,
       eles sao mais suscetiveis a hot spots, nos quais um disco e muito
       ativo e outros ficam ociosos.

     * Um plex striped distribui os dados uniformemente entre cada subdisco.
       Os subdiscos devem ser todos do mesmo tamanho e deve haver pelo menos
       dois subdiscos para distingui-los de um plex concatenado. A maior
       vantagem dos plexes striped e que eles reduzem os hot spots. Ao
       escolher uma faixa de tamanho ideal, de cerca de 256 kB, a carga pode
       ser nivelada nas unidades de componentes. Estender um complexo
       adicionando novos subdiscos e algo tao complicado que o vinum nao o
       implementa.

   Tabela 1, "Organizac,oes Plex do vinum" resume as vantagens e desvantagens
   de cada organizac,ao plex.

   Tabela 1. Organizac,oes Plex do vinum

               Subdiscos   Pode    Deve ser de                                
    Tipo plex   minimos  adicionar   tamanho             Aplicac,ao
                         subdiscos    igual    
                                               Armazenamento de dados grandes 
   concatenado 1         sim       nao         com flexibilidade maxima de    
                                               posicionamento e desempenho    
                                               moderado                       
                                               Alto desempenho em combinac,ao 
   striped     2         nao       sim         com acesso altamente           
                                               concorrente                    

5. Alguns exemplos

   O vinum mantem um banco de dados de configurac,ao que descreve os objetos
   conhecidos de um sistema individual. Inicialmente, o usuario cria o banco
   de dados de configurac,ao a partir de um ou mais arquivos de configurac,ao
   usando gvinum(8). O vinum armazena uma copia de seu banco de dados de
   configurac,ao em cada dispositivo de disco sob seu controle. Este banco de
   dados e atualizado em cada mudanc,a de estado, de modo que uma
   reinicializac,ao restaura com precisao o estado de cada objeto vinum.

  5.1. O arquivo de configurac,ao

   O arquivo de configurac,ao descreve objetos vinum individuais. A
   definic,ao de um volume simples pode ser:

     drive a device /dev/da3h
     volume myvol
       plex org concat
         sd length 512m drive a

   Este arquivo descreve quatro objetos vinum:

     * A linha drive descreve uma partic,ao de disco (drive) e sua
       localizac,ao relativa ao hardware subjacente. E dado o nome simbolico
       a. Essa separac,ao de nomes simbolicos de nomes de dispositivos
       permite que os discos sejam movidos de um local para outro sem
       confusao.

     * A linha volume descreve um volume. O unico atributo obrigatorio e o
       nome, neste caso myvol.

     * A linha plex define um plex. O unico parametro requerido e a
       organizac,ao, neste caso concat. Nenhum nome e necessario, pois o
       sistema gera automaticamente um nome a partir do nome do volume,
       adicionando o sufixo .px, onde x e o numero de o plex no volume.
       Assim, este plex sera chamado myvol.p0.

     * A linha sd descreve um subdisco. As especificac,oes minimas sao o nome
       de uma unidade na qual ira armazena-lo e o tamanho do subdisco. Nenhum
       nome e necessario porque o sistema atribui automaticamente nomes
       derivados do nome do plex adicionando o sufixo .sx, onde x e o numero
       do subdisco no plex. Assim, vinum da ao subdisco o nome myvol.p0.s0.

   Depois de processar este arquivo, o gvinum(8) produz a seguinte saida:

 # gvinum -> create config1
 Configuration summary
 Drives:         1 (4 configured)
 Volumes:        1 (4 configured)
 Plexes:         1 (8 configured)
 Subdisks:       1 (16 configured)

   D a                     State: up       Device /dev/da3h      Avail: 2061/2573 MB (80%)

   V myvol                 State: up       Plexes:       1 Size:      512 MB

   P myvol.p0            C State: up       Subdisks:     1 Size:      512 MB

   S myvol.p0.s0           State: up       PO:        0  B Size:      512 MB

   Esta saida mostra o formato de listagem breve de gvinum(8). Ele esta
   representado graficamente em Figura 4, "Um volume vinum simples ".

   Figura 4. Um volume vinum simples
   Um volume vinum simples

   Esta figura, e as que se seguem, representam um volume, que contem os
   plexes, que por sua vez contem os subdiscos. Neste exemplo, o volume
   contem um plex e o plex contem um subdisco.

   Este volume especifico nao tem nenhuma vantagem especifica sobre uma
   partic,ao de disco convencional. Ele contem um unico plex, por isso nao e
   redundante. O plex contem um unico subdisco, portanto, nao ha diferenc,a
   na alocac,ao de armazenamento de uma partic,ao de disco convencional. As
   sec,oes a seguir ilustram varios metodos de configurac,ao mais
   interessantes.

  5.2. Maior Resiliencia: Espelhamento

   A resiliencia de um volume pode ser aumentada pelo espelhamento. Ao dispor
   um volume espelhado, e importante garantir que os subdiscos de cada plex
   estejam em unidades diferentes, de modo que uma falha no dispositivo nao
   derrubara os dois plexes. A configurac,ao a seguir espelha um volume:

         drive b device /dev/da4h
         volume mirror
       plex org concat
         sd length 512m drive a
           plex org concat
             sd length 512m drive b

   Neste exemplo, nao foi necessario especificar uma definic,ao de drive a
   novamente, ja que o vinum registra todos os objetos em seu banco de dados
   de configurac,ao. Depois de processar esta definic,ao, a configurac,ao se
   parece com:

         Drives:         2 (4 configured)
         Volumes:        2 (4 configured)
         Plexes:         3 (8 configured)
         Subdisks:       3 (16 configured)

         D a                     State: up       Device /dev/da3h       Avail: 1549/2573 MB (60%)
         D b                     State: up       Device /dev/da4h       Avail: 2061/2573 MB (80%)

     V myvol                 State: up       Plexes:       1 Size:        512 MB
     V mirror                State: up       Plexes:       2 Size:        512 MB

     P myvol.p0            C State: up       Subdisks:     1 Size:        512 MB
     P mirror.p0           C State: up       Subdisks:     1 Size:        512 MB
     P mirror.p1           C State: initializing     Subdisks:     1 Size:        512 MB

     S myvol.p0.s0           State: up       PO:        0  B Size:        512 MB
         S mirror.p0.s0          State: up       PO:        0  B Size:        512 MB
         S mirror.p1.s0          State: empty    PO:        0  B Size:        512 MB

   Figura 5, "Um volume vinum espelhado" mostra a estrutura graficamente.

   Figura 5. Um volume vinum espelhado
   Um volume vinum espelhado

   Neste exemplo, cada plex contem os 512 MB completos do espac,o de
   enderec,o. Como no exemplo anterior, cada plex contem apenas um unico
   subdisco.

  5.3. Otimizando o desempenho

   O volume espelhado no exemplo anterior e mais resistente a falhas do que
   um volume nao espelhado, mas seu desempenho e menor, pois cada gravac,ao
   no volume requer uma gravac,ao nas duas unidades, utilizando uma grande
   parte da largura de banda total do disco. As considerac,oes de desempenho
   exigem uma abordagem diferente: em vez de espelhar, os dados sao
   distribuidos em quantas unidades de disco forem possiveis. A configurac,ao
   a seguir mostra um volume com um plex distribuido em quatro unidades de
   disco:

         drive c device /dev/da5h
         drive d device /dev/da6h
         volume stripe
         plex org striped 512k
           sd length 128m drive a
           sd length 128m drive b
           sd length 128m drive c
           sd length 128m drive d

   Como antes, nao e necessario definir as unidades que ja sao conhecidas por
   vinum. Depois de processar esta definic,ao, a configurac,ao se parece com:

         Drives:         4 (4 configured)
         Volumes:        3 (4 configured)
         Plexes:         4 (8 configured)
         Subdisks:       7 (16 configured)

     D a                     State: up       Device /dev/da3h        Avail: 1421/2573 MB (55%)
     D b                     State: up       Device /dev/da4h        Avail: 1933/2573 MB (75%)
     D c                     State: up       Device /dev/da5h        Avail: 2445/2573 MB (95%)
     D d                     State: up       Device /dev/da6h        Avail: 2445/2573 MB (95%)

     V myvol                 State: up       Plexes:       1 Size:        512 MB
     V mirror                State: up       Plexes:       2 Size:        512 MB
     V striped               State: up       Plexes:       1 Size:        512 MB

     P myvol.p0            C State: up       Subdisks:     1 Size:        512 MB
     P mirror.p0           C State: up       Subdisks:     1 Size:        512 MB
     P mirror.p1           C State: initializing     Subdisks:     1 Size:        512 MB
     P striped.p1            State: up       Subdisks:     1 Size:        512 MB

     S myvol.p0.s0           State: up       PO:        0  B Size:        512 MB
     S mirror.p0.s0          State: up       PO:        0  B Size:        512 MB
     S mirror.p1.s0          State: empty    PO:        0  B Size:        512 MB
     S striped.p0.s0         State: up       PO:        0  B Size:        128 MB
     S striped.p0.s1         State: up       PO:      512 kB Size:        128 MB
     S striped.p0.s2         State: up       PO:     1024 kB Size:        128 MB
     S striped.p0.s3         State: up       PO:     1536 kB Size:        128 MB

   Figura 6. Um volume vinum concatenado
   Um volume vinum concatenado

   Este volume e representado em Figura 6, "Um volume vinum concatenado". A
   escuridao das strips indica a posic,ao dentro do espac,o de enderec,o
   plex, onde as faixas mais claras vem primeiro e as mais escuras por
   ultimo.

  5.4. Resiliencia e Desempenho

   Com hardware suficiente, e possivel construir volumes que mostrem maior
   resiliencia e melhor desempenho em comparac,ao com as partic,oes padrao
   UNIX(R). Um arquivo de configurac,ao tipico pode ser:

         volume raid10
       plex org striped 512k
         sd length 102480k drive a
         sd length 102480k drive b
         sd length 102480k drive c
         sd length 102480k drive d
         sd length 102480k drive e
       plex org striped 512k
         sd length 102480k drive c
         sd length 102480k drive d
         sd length 102480k drive e
         sd length 102480k drive a
         sd length 102480k drive b

   Os subdiscos do segundo plex sao compensados por duas unidades daquelas do
   primeiro plex. Isso ajuda a garantir que as gravac,oes nao vao para os
   mesmos subdiscos, mesmo que uma transferencia passe por duas unidades.

   Figura 7, "Um volume vinum espelhado e concatenado" representa a estrutura
   deste volume.

   Figura 7. Um volume vinum espelhado e concatenado
   Um volume vinum espelhado e concatenado

6. Nomeac,ao de Objetos

   O vinum atribui nomes padroes a plexes e subdiscos, embora eles possam ser
   substituidos. Substituir os nomes padroes nao e recomendado, pois nao isso
   traz nenhuma vantagem significativa e pode causar confusao.

   Os nomes podem conter qualquer caractere nao-branco, mas e recomendado
   restringi-los a letras, digitos e caracteres de sublinhado. Os nomes de
   volumes, plexes e subdiscos podem ter ate 64 caracteres e os nomes das
   unidades podem ter ate 32 caracteres.

   Os objetos vinum sao designados a device nodes na hierarquia /dev/gvinum.
   A configurac,ao mostrada acima faria com que o vinum criasse os seguintes
   device nodes:

     * Entradas de dispositivos para cada volume. Estes sao os principais
       dispositivos usados pelo vinum. A configurac,ao acima incluiria os
       dispositivos /dev/gvinum/myvol, /dev/gvinum/mirror,
       /dev/gvinum/striped, /dev/gvinum/raid5 e o /dev/gvinum/raid10.

     * Todos os volumes recebem entradas diretas em /dev/gvinum/.

     * Os diretorios /dev/gvinum/plex, e /dev/gvinum/sd sao aqueles que
       contem device nodes para cada plex e para cada subdisco,
       respectivamente.

   Por exemplo, considere o seguinte arquivo de configurac,ao:

         drive drive1 device /dev/sd1h
         drive drive2 device /dev/sd2h
         drive drive3 device /dev/sd3h
         drive drive4 device /dev/sd4h
     volume s64 setupstate
       plex org striped 64k
         sd length 100m drive drive1
         sd length 100m drive drive2
         sd length 100m drive drive3
         sd length 100m drive drive4

   Depois de processar este arquivo, o gvinum(8) cria a seguinte estrutura em
   /dev/gvinum:

         drwxr-xr-x  2 root  wheel       512 Apr 13
 16:46 plex
         crwxr-xr--  1 root  wheel   91,   2 Apr 13 16:46 s64
         drwxr-xr-x  2 root  wheel       512 Apr 13 16:46 sd

     /dev/vinum/plex:
     total 0
     crwxr-xr--  1 root  wheel   25, 0x10000002 Apr 13 16:46 s64.p0

     /dev/vinum/sd:
     total 0
     crwxr-xr--  1 root  wheel   91, 0x20000002 Apr 13 16:46 s64.p0.s0
     crwxr-xr--  1 root  wheel   91, 0x20100002 Apr 13 16:46 s64.p0.s1
     crwxr-xr--  1 root  wheel   91, 0x20200002 Apr 13 16:46 s64.p0.s2
     crwxr-xr--  1 root  wheel   91, 0x20300002 Apr 13 16:46 s64.p0.s3

   Embora seja recomendado que os plexes e subdiscos nao sejam atribuidos a
   nomes especificos, as unidades vinum devem ser nomeadas. Isso possibilita
   mover uma unidade para um local diferente e ainda reconhece-la
   automaticamente. Os nomes dos drives podem ter ate 32 caracteres.

  6.1. Criando sistemas de arquivos

   Para o sistema os volumes sao identicos aos discos, com uma excec,ao. Ao
   contrario das unidades UNIX(R), o vinum nao particiona os volumes, e,
   portanto, nao contem uma tabela de partic,oes. Isso exigiu modificac,ao em
   alguns dos utilitarios de disco, notavelmente no newfs(8), para que ele
   nao tente interpretar a ultima letra de um nome do volume vinum como um
   identificador de partic,ao. Por exemplo, uma unidade de disco pode ter um
   nome como /dev/ad0a ou /dev/da2h. Esses nomes representam a primeira
   partic,ao (a) no primeiro (0) disco IDE (ad) e a oitava partic,ao (h) no
   terceiro (2) disco SCSI (da) respectivamente. Por outro lado, um volume
   vinum pode ser chamado de /dev/gvinum/concat, que nao tem relac,ao com o
   nome da partic,ao.

   Para criar um sistema de arquivos neste volume, use newfs(8):

 # newfs /dev/gvinum/concat

7. Configurando o vinum

   O kernel GENERIC nao suporta o vinum. E possivel compilar um kernel
   customizado que inclua o suporte estatico ao vinum, mas isso nao e
   recomendado. A maneira padrao de iniciar o vinum e como um modulo do
   kernel. O uso do kldload(8) nao e necessario porque quando o gvinum(8) e
   iniciado, ele verifica se o modulo ja foi carregado e, se ele nao tiver
   sido, ele sera carregado automaticamente.

  7.1. Comec,ando

   O vinum armazena as informac,oes de configurac,ao nos slices dos discos
   essencialmente da mesma forma que nos arquivos de configurac,ao. Ao ler a
   partir do banco de dados de configurac,ao, o vinum reconhece um numero de
   palavras-chave que nao sao permitidas nos arquivos de configurac,ao. Por
   exemplo, uma configurac,ao de disco pode conter o seguinte texto:

 volume myvol state up
 volume bigraid state down
 plex name myvol.p0 state up org concat vol myvol
 plex name myvol.p1 state up org concat vol myvol
 plex name myvol.p2 state init org striped 512b vol myvol
 plex name bigraid.p0 state initializing org raid5 512b vol bigraid
 sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b
 sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b
 sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b
 sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b
 sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b
 sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b
 sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b
 sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b
 sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b
 sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b
 sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b
 sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b
 sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b

   As diferenc,as obvias aqui sao a presenc,a de informac,oes explicitas de
   localizac,ao e nomeac,ao, as quais sao ambas permitidas mas
   desencorajadas, e as informac,oes sobre os estados. O vinum nao armazena
   informac,oes sobre unidades nas informac,oes de configurac,ao. Ele
   encontra as unidades varrendo as unidades de disco configuradas em busca
   de partic,oes com um rotulo vinum. Isso permite que o vinum identifique as
   unidades corretamente, mesmo que elas tenham recebido diferentes IDs de
   unidade UNIX(R).

    7.1.1. Inicializac,ao automatica

   O Gvinum apresenta sempre uma inicializac,ao automatica assim que o modulo
   do kernel e carregado, atraves do loader.conf(5). Para carregar o modulo
   Gvinum no momento da inicializac,ao, adicione geom_vinum_load="YES" ao
   arquivo /boot/loader.conf.

   Quando o vinum e iniciado com gvinum start, o vinum le o banco de dados de
   configurac,ao de uma das unidades vinum. Em circunstancias normais, cada
   unidade contem uma copia identica do banco de dados de configurac,ao,
   portanto, nao importa qual unidade e lida. Apos uma falha, no entanto, o
   vinum deve determinar qual unidade foi atualizada mais recentemente e ler
   a configurac,ao desta unidade. Em seguida, atualiza a configurac,ao, se
   necessario, de unidades progressivamente a partir das mais antigas.

8. Usando o vinum para o sistema de arquivos raiz

   Para uma maquina que tenha sistemas de arquivos totalmente espelhados
   usando vinum, e desejavel tambem espelhar o sistema de arquivos raiz.
   Efetuar esta configurac,ao e menos trivial do que espelhar um sistema de
   arquivos arbitrario porque:

     * O sistema de arquivos raiz deve estar disponivel muito cedo durante o
       processo de inicializac,ao, portanto a infraestrutura vinum ja deve
       estar disponivel no momento.

     * O volume que contem o sistema de arquivos raiz tambem contem a
       auto-inicializac,ao do sistema e o kernel. Eles devem ser lidos usando
       os utilitarios nativos do sistema, como o BIOS, que muitas vezes nao
       pode ser instruido sobre os detalhes do vinum.

   Nas sec,oes a seguir, o termo "volume raiz" e geralmente usado para
   descrever o volume vinum que contem o sistema de arquivos raiz (/).

  8.1. Iniciando o vinum cedo o suficiente para o sistema de arquivos raiz

   O vinum deve estar disponivel no inicio da inicializac,ao do sistema pois
   o loader(8) deve ser capaz de carregar o modulo do kernel vinum antes de
   iniciar o kernel. Isto pode ser feito colocando esta linha no
   /boot/loader.conf:

 geom_vinum_load="YES"

  8.2. Tornando um volume raiz baseado em vinum acessivel ao Bootstrap

   O bootstrap atual do FreeBSD tem apenas 7.5 KB de codigo e nao entende as
   estruturas internas do vinum. Isso significa que nao e possivel analisar
   os dados de configurac,ao vinum ou descobrir os elementos de um volume de
   inicializac,ao. Assim, algumas soluc,oes alternativas sao necessarias para
   fornecer ao codigo de inicializac,ao a ilusao de que ele esta trabalhando
   com uma partic,ao padrao a que contem o sistema de arquivos raiz.

   Para que isso seja possivel, os seguintes requisitos devem ser atendidos
   para o volume raiz:

     * O volume raiz nao pode ser uma stripe ou RAID -5.

     * O volume raiz nao deve conter mais de um subdisco concatenado por
       plex.

   Observe que e desejavel e possivel usar varios plexes, cada um contendo
   uma replica do sistema de arquivos raiz. O processo de bootstrap usara
   apenas uma replica para localizar o bootstrap e todos os arquivos de
   inicializac,ao, ate que o kernel monte o sistema de arquivos raiz. Cada
   subdisco dentro desses plexes precisa da sua propria ilusao de partic,ao
   a, para que o respectivo dispositivo seja inicializavel. Nao e
   estritamente necessario que cada uma dessas falsas partic,oes a estejam
   localizadas no mesmo deslocamento dentro de seu dispositivo, em
   comparac,ao com outros dispositivos contendo plexes do volume raiz. No
   entanto, e provavelmente uma boa ideia criar os volumes vinum dessa forma
   para que os dispositivos espelhados resultantes sejam simetricos, para
   evitar confusao.

   Para configurar essas partic,oes a para cada dispositivo contendo parte do
   volume raiz, e necessario o seguinte:

    1. A localizac,ao, offset desde o inicio do dispositivo, e o tamanho do
       subdisco desse dispositivo que faz parte do volume raiz precisam ser
       examinados, usando o comando:

 # gvinum l -rv root

       Os offsets (deslocamentos) e tamanhos do vinum sao medidos em bytes.
       Eles devem ser divididos por 512 para obter os numeros de blocos que
       serao usados pelo bsdlabel.

    2. Execute este comando para cada dispositivo que participa do volume
       raiz:

 # bsdlabel -e devname

       No comando acima devname deve ser o nome do disco, como da0 para
       discos sem uma tabela de slices, ou o nome da slice, como ad0s1.

       Se ja existir uma partic,ao a no dispositivo a partir de um sistema de
       arquivos raiz pre-vinum, ela deve ser renomeada para outra coisa para
       que permanec,a acessivel (apenas nesse caso), mas ela nao sera mais
       usada por padrao para inicializar o sistema. Um sistema de arquivos
       raiz atualmente montado nao pode ser renomeado, portanto, de forma que
       o processo ser executado quando o sistema for inicializado a partir de
       uma midia "Fixit" ou em um processo de duas etapas em que, em um
       espelho, o disco que ainda nao foi inicializado e manipulado primeiro.

       O offset da partic,ao vinum neste dispositivo (se houver) deve ser
       adicionado ao deslocamento do respectivo subdisco de volume raiz neste
       dispositivo. O valor resultante se tornara o valor do offset para a
       nova partic,ao a. O valor do size para esta partic,ao tambem pode ser
       obtido a partir do calculo acima. O fstype deve ser 4.2BSD. Os valores
       de fsize, bsize e cpg devem ser escolhidos para corresponder ao
       sistema de arquivos atual, embora eles sejam relativamente sem
       importancia dentro deste contexto.

       Desta forma, uma nova partic,ao a sera estabelecida sobrepondo a
       partic,ao vinum neste dispositivo. O bsdlabel so permitira essa
       sobreposic,ao se a partic,ao vinum tiver sido marcada corretamente
       usando o modo fstype do vinum.

    3. Temos agora uma falsa partic,ao a em cada dispositivo que possui uma
       replica do volume raiz. E altamente recomendavel verificar o resultado
       usando um comando como:

 # fsck -n /dev/devnamea

   Deve ser lembrado que todos os arquivos contendo informac,oes de controle
   devem ser relativos ao sistema de arquivos raiz no volume vinum e que, ao
   configurarmos um novo volume raiz vinum, ele pode nao corresponder o
   sistema de arquivos raiz que esta atualmente ativo. Entao, em particular,
   o /etc/fstab e /boot/loader.conf precisam ser ajustados.

   Na proxima reinicializac,ao, o bootstrap deve descobrir as informac,oes de
   controle apropriadas do novo sistema de arquivos raiz baseado no vinum e
   agir de acordo. No final do processo de inicializac,ao do kernel, apos
   todos os dispositivos terem sido anunciados, o aviso de destaque que
   mostra o sucesso desta configurac,ao e uma mensagem como:

 Mounting root from ufs:/dev/gvinum/root

  8.3. Exemplo de uma configurac,ao raiz baseada em vinum

   Depois que o volume raiz vinum foi configurado, a saida de gvinum l -rv
   root pode parecer com:

 ...
 Subdisk root.p0.s0:
                 Size:        125829120 bytes (120 MB)
                 State: up
                 Plex root.p0 at offset 0 (0  B)
                 Drive disk0 (/dev/da0h) at offset 135680 (132 kB)

 Subdisk root.p1.s0:
                 Size:        125829120 bytes (120 MB)
                 State: up
                 Plex root.p1 at offset 0 (0  B)
                 Drive disk1 (/dev/da1h) at offset 135680 (132 kB)

   Os valores a serem observados sao 135680 para o offset, relativo `a
   partic,ao /dev/da0h. Isso se traduz em 265 blocos de discos de 512 bytes
   nos termos do bsdlabel. Da mesma forma, o tamanho desse volume raiz e de
   245760 blocos de 512 bytes. O /dev/da1h, contem a segunda replica deste
   volume raiz, e possui uma configurac,ao simetrica.

   O bsdlabel para esses dispositivos pode se parecer com:

 ...
 8 partitions:
 #        size   offset    fstype   [fsize bsize bps/cpg]
   a:   245760      281    4.2BSD     2048 16384     0   # (Cyl.    0*- 15*)
   c: 71771688        0    unused        0     0         # (Cyl.    0 - 4467*)
   h: 71771672       16     vinum                        # (Cyl.    0*- 4467*)

   Pode-se observar que o parametro size para a falsa partic,ao a corresponde
   ao valor descrito acima, enquanto o parametro offset e a soma do
   deslocamento dentro da partic,ao vinum h, e o offset desta partic,ao
   dentro do dispositivo ou slice. Esta e uma configurac,ao tipica que e
   necessaria para evitar o problema descrito em Sec,ao 8.4.3, "Nada carrega
   e o Bootstrap entra em panic". A partic,ao a inteira esta completamente
   dentro da partic,ao h que contem todos os dados vinum para este
   dispositivo.

   No exemplo acima, todo o dispositivo e dedicado ao vinum e nao ha sobra de
   partic,ao raiz pre-vinum.

  8.4. Soluc,oes de problemas

   A lista a seguir contem algumas armadilhas e soluc,oes conhecidas.

    8.4.1. Sistema de bootstrap carrega, mas o sistema nao

   Se por algum motivo o sistema nao continuar a inicializac,ao, o bootstrap
   pode ser interrompido pressionando espac,o no aviso de 10 segundos. A
   variavel vinum.autostart do loader pode ser examinada digitando show e
   manipulada usando set ou unset.

   Se o modulo do kernel vinum ainda nao estava na lista de modulos para
   carregar automaticamente, digite load geom_vinum.

   Quando estiver pronto, o processo de inicializac,ao pode ser continuado
   digitando-se boot -as, no qual -as solicita ao kernel que pec,a ao sistema
   de arquivos raiz para montar (-a) e fazer com que o processo de
   inicializac,ao pare no modo single user(-s), em que o sistema de arquivos
   raiz e montado como somente leitura. Dessa forma, mesmo que apenas um plex
   de um volume multi-plex tenha sido montado, nao estaremos arriscando
   nenhuma inconsistencia de dados entre os plexes.

   No prompt solicitando que um sistema de arquivos raiz seja montado,
   qualquer dispositivo que contenha um sistema de arquivos raiz valido pode
   ser inserido. Se o /etc/fstab estiver configurado corretamente, o padrao
   deve ser algo como ufs:/dev/gvinum/root. Uma opc,ao alternativa tipica
   seria algo como ufs:da0d, que poderia ser uma partic,ao hipotetica
   contendo o sistema de arquivos raiz pre-vinum. Deve-se tomar cuidado se
   uma das partic,oes alias a for inserida aqui, para verificar se ela
   realmente faz referencia aos subdiscos do dispositivo raiz vinum, porque
   em uma configurac,ao espelhada, isso apenas montaria uma parte de um
   dispositivo raiz espelhado. Se este sistema de arquivos tiver que ser
   montado no modo read-write mais tarde, sera necessario remover o(s)
   outro(s) plex(es) do volume raiz vinum, ja que esses plexes carregariam
   dados inconsistentes.

    8.4.2. Apenas o bootstrap primario carrega

   Se o /boot/loader falhar ao carregar, mas o bootstrap primario ainda
   carregar (visivel por um unico trac,o na coluna esquerda da tela logo apos
   o processo de boot ser iniciado), uma tentativa pode ser feita para
   interromper o bootstrap primario pressionando espac,o. Isso fara com que o
   bootstrap pare no estagio dois. Uma tentativa pode ser feita aqui para
   inicializar uma partic,ao alternativa, como a partic,ao que contem o
   sistema de arquivos raiz anterior que foi movido de a.

    8.4.3. Nada carrega e o Bootstrap entra em panic

   Esta situac,ao acontecera se o bootstrap tiver sido destruido pela
   instalac,ao do vinum. Infelizmente, o vinum acidentalmente deixa apenas 4
   KB no inicio de sua partic,ao livre antes de comec,ar a escrever suas
   informac,oes de cabec,alho vinum. No entanto, o estagio um e dois
   bootstraps mais o bsdlabel exigem 8 KB. Portanto, se uma partic,ao vinum
   tiver sido iniciada no offset 0 dentro de uma slice ou disco que deveria
   ser inicializavel, a configurac,ao do vinum ira estragar o bootstrap.

   Da mesma forma, se a situac,ao acima foi recuperada, inicializando de uma
   midia "Fixit", e o bootstrap foi reinstalado usando bsdlabel -B como
   descrito em
   ../../../../doc/en_US.ISO8859-1/books/handbook/boot.html#boot-boot1, o
   bootstrap ira estragar o cabec,alho vinum e o vinum nao encontrara mais
   seu(s) disco(s). Entretando nenhum dado de configurac,ao real do vinum e
   nenhum volume vinum de dados foi descartado, sendo possivel recupera-los
   digitando de novo exatamente as mesmas configurac,oes do vinum, a
   situac,ao e dificil de corrigir de forma definitiva. Pois sera necessario
   mover toda a partic,ao vinum em pelo menos 4 KB, para que o cabec,alho
   vinum e o bootstrap do sistema nao colidam mais.
