Gerenciamento de sistemas de arquivos
Criação, modificação e administração de sistemas de arquivo no Red Hat Enterprise Linux 8
Last Updated: 2021-02-27
Criação, modificação e administração de sistemas de arquivo no Red Hat Enterprise Linux 8
Enter your first name here. Enter your surname here.
Enter your organisation's name here. Enter your organisational division here.
Enter your email address here.
Copyright © 2021 | You need to change the HOLDER entity in the en-
US/Managing_file_systems.ent file | This material may only be distributed subject to the terms and conditions set forth in the GNU Free Documentation License (GFDL), V1.2 or later (the latest version is presently available at http://www.gnu.org/licenses/fdl.txt).
Resumo
Esta coleção de documentação fornece instruções sobre como gerenciar efetivamente os sistemas de arquivo no Red Hat Enterprise Linux 8.
. . . . . . . . . . . .
. . . .
. . . .
Índice
TORNANDO O CÓDIGO ABERTO MAIS INCLUSIVO
FORNECENDO FEEDBACK SOBRE A DOCUMENTAÇÃO DA RED HAT CAPÍTULO 1. VISÃO GERAL DOS SISTEMAS DE ARQUIVO DISPONÍVEIS
1.1. TIPOS DE SISTEMAS DE ARQUIVO 1.2. SISTEMAS DE ARQUIVO LOCAIS
Sistemas de arquivo locais disponíveis 1.3. O SISTEMA DE ARQUIVO XFS
Características de desempenho 1.4. O SISTEMA DE ARQUIVO EXT4 1.5. COMPARAÇÃO DE XFS E EXT4
1.6. ESCOLHENDO UM SISTEMA DE ARQUIVO LOCAL 1.7. SISTEMAS DE ARQUIVOS EM REDE
Sistemas de arquivos em rede disponíveis
1.8. SISTEMAS DE ARQUIVOS DE ARMAZENAMENTO COMPARTILHADO Comparação com sistemas de arquivos em rede
Concorrência
Características de desempenho
Sistemas de arquivos de armazenamento compartilhado disponíveis
1.9. ESCOLHENDO ENTRE SISTEMAS DE ARQUIVOS EM REDE E DE ARMAZENAMENTO COMPARTILHADO 1.10. SISTEMAS DE ARQUIVOS DE GERENCIAMENTO DE VOLUME
Sistemas de arquivos de gerenciamento de volume disponíveis
CAPÍTULO 2. GERENCIAMENTO DO ARMAZENAMENTO LOCAL USANDO AS FUNÇÕES DO SISTEMA RHEL 2.1. INTRODUÇÃO À FUNÇÃO DE ARMAZENAMENTO
2.2. PARÂMETROS QUE IDENTIFICAM UM DISPOSITIVO DE ARMAZENAMENTO NO PAPEL DO SISTEMA DE ARMAZENAMENTO
2.3. EXEMPLO LIVRO DE REPRODUÇÃO POSSÍVEL PARA CRIAR UM SISTEMA DE ARQUIVO XFS EM UM DISPOSITIVO DE BLOCO
2.4. EXEMPLO LIVRO DE REPRODUÇÃO POSSÍVEL PARA MONTAR PERSISTENTEMENTE UM SISTEMA DE ARQUIVO
2.5. EXEMPLO LIVRO DE EXERCÍCIOS POSSÍVEL PARA GERENCIAR VOLUMES LÓGICOS
2.6. EXEMPLO LIVRO DE REPRODUÇÃO POSSÍVEL PARA PERMITIR O DESCARTE EM BLOCO ONLINE 2.7. EXEMPLO LIVRO DE REPRODUÇÃO POSSÍVEL PARA CRIAR E MONTAR UM SISTEMA DE ARQUIVO EXT4
2.8. EXEMPLO LIVRO DE REPRODUÇÃO POSSÍVEL PARA CRIAR E MONTAR UM SISTEMA DE ARQUIVO EXT3
2.9. CONFIGURAÇÃO DE UM VOLUME RAID UTILIZANDO A FUNÇÃO DO SISTEMA DE ARMAZENAMENTO 2.10. CONFIGURAÇÃO DE UM POOL LVM COM RAID UTILIZANDO A FUNÇÃO DE SISTEMA DE
ARMAZENAMENTO
2.11. CRIAÇÃO DE UM VOLUME CODIFICADO LUKS USANDO A FUNÇÃO DE ARMAZENAMENTO CAPÍTULO 3. MONTAGEM DE AÇÕES DA NFS
3.1. INTRODUÇÃO AO NFS 3.2. VERSÕES NFS SUPORTADAS
Versão padrão da NFS
Características das versões menores do NFS 3.3. SERVIÇOS REQUERIDOS PELA NFS
Os serviços de RPC com NFSv4
9 10 11 11 12 12 12 13 14 14 15 16 17 17 17 17 17 18 18 18 18
20 20 20 21 22 22 23 24 24 25 26 28 30 30 30 30 30 31 32
. . . .
. . . .
. . . . 3.4. FORMATOS DO NOME DO HOST NFS
3.5. INSTALANDO O NFS
3.6. DESCOBRINDO AS EXPORTAÇÕES DA NFS
3.7. MONTAGEM DE UM COMPARTILHAMENTO NFS COM MONTAGEM 3.8. OPÇÕES COMUNS DE MONTAGEM NFS
3.9. INFORMAÇÕES RELACIONADAS
CAPÍTULO 4. EXPORTAÇÃO DE AÇÕES DA NFS 4.1. INTRODUÇÃO AO NFS
4.2. VERSÕES NFS SUPORTADAS Versão padrão da NFS
Características das versões menores do NFS
4.3. OS PROTOCOLOS TCP E UDP EM NFSV3 E NFSV4 4.4. SERVIÇOS REQUERIDOS PELA NFS
Os serviços de RPC com NFSv4
4.5. FORMATOS DO NOME DO HOST NFS 4.6. CONFIGURAÇÃO DO SERVIDOR NFS
4.6.1. O arquivo de configuração /etc/exporta Entrada de exportação
Opções padrão
Opções padrão e anuladas 4.6.2. A utilidade das exportações
Opções comuns de exportação 4.7. NFS E RPCBIND
4.8. INSTALANDO O NFS
4.9. INICIANDO O SERVIDOR NFS
4.10. SOLUÇÃO DE PROBLEMAS DE NFS E RPCBIND
4.11. CONFIGURANDO O SERVIDOR NFS PARA RODAR ATRÁS DE UM FIREWALL 4.12. EXPORTANDO A COTA DE RPC ATRAVÉS DE UM FIREWALL
4.13. HABILITAÇÃO DO NFS SOBRE O RDMA (NFSORDMA) 4.14. CONFIGURAÇÃO DE UM SERVIDOR NFSV4 APENAS
4.14.1. Benefícios e desvantagens de um servidor NFSv4 somente para NFS 4.14.2. NFS e rpcbind
4.14.3. Configuração do servidor NFS para suportar apenas o NFSv4 4.14.4. Verificação da configuração apenas do NFSv4
4.15. INFORMAÇÕES RELACIONADAS CAPÍTULO 5. SEGURANÇA DO NFS
5.1. SEGURANÇA NFS COM AUTH_SYS E CONTROLES DE EXPORTAÇÃO 5.2. SEGURANÇA NFS COM AUTH_GSS
5.3. CONFIGURAÇÃO DE UM SERVIDOR E CLIENTE NFS PARA USAR O KERBEROS 5.4. OPÇÕES DE SEGURANÇA NFSV4
5.5. PERMISSÕES DE ARQUIVO EM EXPORTAÇÕES NFS MONTADAS CAPÍTULO 6. HABILITANDO LAYOUTS PNFS SCSI EM NFS
6.1. A TECNOLOGIA PNFS 6.2. LAYOUTS DO PNFS SCSI
Operações entre o cliente e o servidor Reservas de dispositivos
6.3. VERIFICAÇÃO DE UM DISPOSITIVO SCSI COMPATÍVEL COM O PNFS 6.4. CONFIGURANDO O PNFS SCSI NO SERVIDOR
6.5. INSTALAÇÃO DO PNFS SCSI NO CLIENTE
6.6. LIBERAÇÃO DA RESERVA DO PNFS SCSI NO SERVIDOR
6.7. MONITORAMENTO DA FUNCIONALIDADE DOS LAYOUTS SCSI DO PNFS
32 33 33 34 34 36 37 37 37 37 37 38 38 39 39 40 40 40 41 42 42 42 43 44 44 44 45 46 47 48 48 48 49 49 50 51 51 51 51 52 53 54 54 54 54 55 55 56 56 57 58
. . . .
. . . .
. . . .
. . . . 6.7.1. Verificação das operações pNFS SCSI a partir do servidor usando o nfsstat
6.7.2. Verificação das operações pNFS SCSI por parte do cliente utilizando montarias CAPÍTULO 7. COMEÇANDO COM O FS-CACHE
7.1. VISÃO GERAL DO FS-CACHE 7.2. GARANTIA DE DESEMPENHO 7.3. MONTANDO UM CACHE 7.4. USANDO O CACHE COM NFS
7.4.1. Configuração do compartilhamento de cache NFS 7.4.2. Limitações de cache com NFS
7.5. CONFIGURAÇÃO DOS LIMITES DE ABATE DE CACHES
7.6. OBTENÇÃO DE INFORMAÇÕES ESTATÍSTICAS DO MÓDULO FSCACHE KERNEL 7.7. REFERÊNCIAS DO FS-CACHE
CAPÍTULO 8. MONTAGEM DE UMA AÇÃO SMB NO RED HAT ENTERPRISE LINUX 8.1. VERSÕES DE PROTOCOLO SMB SUPORTADAS
8.2. SUPORTE A EXTENSÕES UNIX
8.3. MONTAGEM MANUAL DE UMA AÇÃO SMB
8.4. MONTAGEM AUTOMÁTICA DE UM COMPARTILHAMENTO SMB QUANDO O SISTEMA INICIA 8.5. AUTENTICAÇÃO PARA UMA AÇÃO SMB USANDO UM ARQUIVO DE CREDENCIAIS
8.6. EXECUÇÃO DE UMA MONTAGEM SMB MULTIUSUÁRIO 8.6.1. Montagem de uma ação com a opção multiusuário
8.6.2. Verificar se uma ação SMB é montada com a opção multiusuário 8.6.3. Acesso a uma ação como um usuário
8.7. OPÇÕES DE MONTAGEM FREQÜENTEMENTE UTILIZADAS
CAPÍTULO 9. VISÃO GERAL DOS ATRIBUTOS DE NOMEAÇÃO PERSISTENTES 9.1. DESVANTAGENS DOS ATRIBUTOS DE NOMENCLATURA NÃO-PERSISTENTES 9.2. SISTEMA DE ARQUIVOS E IDENTIFICADORES DE DISPOSITIVOS
Identificadores do sistema de arquivo Identificadores de dispositivos Recomendações
9.3. NOMES DE DISPOSITIVOS GERENCIADOS PELO MECANISMO UDEV EM /DEV/DISCO/
9.3.1. Identificadores do sistema de arquivo O atributo UUID em /dev/disco/by-uuid/
O atributo Label in /dev/disk/by-label/
9.3.2. Identificadores de dispositivos O atributo WWID em /dev/disco/by-id/
O atributo Partição UUID em /dev/disco/by-partuuid O atributo Caminho em /dev/disco/by-path/
9.4. O IDENTIFICADOR MUNDIAL COM DM MULTIPATH
9.5. LIMITAÇÕES DA CONVENÇÃO DE NOMENCLATURA DE DISPOSITIVOS UDEV 9.6. LISTAGEM DE ATRIBUTOS DE NOMEAÇÃO PERSISTENTES
9.7. MODIFICAÇÃO DE ATRIBUTOS DE NOMEAÇÃO PERSISTENTES CAPÍTULO 10. COMEÇANDO COM AS DIVISÓRIAS
10.1. VISUALIZAÇÃO DA MESA DIVISÓRIA
10.1.1. Visualizando a mesa divisória com separação 10.1.2. Exemplo de saída de parted print
10.2. CRIAÇÃO DE UMA TABELA DE PARTIÇÃO EM UM DISCO 10.2.1. Considerações antes de modificar as partições em um disco
O número máximo de divisórias O tamanho máximo de uma divisória Alinhamento de tamanhos
58 59 60 60 61 61 62 63 64 65 65 66 67 67 68 68 69 70 70 71 71 71 72 74 74 75 75 75 75 75 76 76 76 76 76 77 77 77 78 79 80 82 82 82 82 83 83 84 84 84
. . . . 10.2.2. Comparação dos tipos de mesas divisórias
10.2.3. Partições de disco MBR 10.2.4. Partições MBR estendidas 10.2.5. Tipos de divisórias MBR 10.2.6. Tabela de partição do GUID
10.2.7. Criação de uma tabela de partição em um disco com partição 10.3. CRIANDO UMA DIVISÓRIA
10.3.1. Considerações antes de modificar as partições em um disco O número máximo de divisórias
O tamanho máximo de uma divisória Alinhamento de tamanhos
10.3.2. Tipos de partição
Tipos de partição ou bandeiras
Tipo de sistema de arquivo de partição 10.3.3. Esquema de nomenclatura das partições 10.3.4. Pontos de montagem e partições de disco 10.3.5. Criação de uma divisória com separação 10.3.6. Definição de um tipo de divisória com fdisk 10.4. REMOÇÃO DE UMA DIVISÓRIA
10.4.1. Considerações antes de modificar as partições em um disco O número máximo de divisórias
O tamanho máximo de uma divisória Alinhamento de tamanhos
10.4.2. Remoção de uma divisória com separação 10.5. REDIMENSIONAMENTO DE UMA DIVISÓRIA
10.5.1. Considerações antes de modificar as partições em um disco O número máximo de divisórias
O tamanho máximo de uma divisória Alinhamento de tamanhos
10.5.2. Redimensionamento de uma divisória com separação 10.6. ESTRATÉGIAS PARA REPARTICIONAR UM DISCO
10.6.1. Utilização de espaço livre não particionado 10.6.2. Usando o espaço de uma divisória não utilizada 10.6.3. Usando o espaço livre de uma divisória ativa
10.6.3.1. Repartição destrutiva 10.6.3.2. Repartição não-destrutiva
10.6.3.2.1. Compressão de dados existentes
10.6.3.2.2. Redimensionamento da divisória existente 10.6.3.2.3. Criação de novas divisórias
CAPÍTULO 11. COMEÇANDO COM XFS 11.1. O SISTEMA DE ARQUIVO XFS
Características de desempenho
11.2. CRIAÇÃO DE UM SISTEMA DE ARQUIVOS XFS 11.2.1. Criando um sistema de arquivo XFS com mkfs.xfs
11.2.2. Criação de um sistema de arquivo XFS em um dispositivo de bloco usando funções do sistema RHEL 11.2.2.1. Exemplo Livro de reprodução possível para criar um sistema de arquivo XFS em um dispositivo de bloco
11.2.2.2. Recursos adicionais
11.3. CÓPIA DE SEGURANÇA DE UM SISTEMA DE ARQUIVO XFS 11.3.1. Características do backup do XFS
11.3.2. Cópia de segurança de um sistema de arquivo XFS com xfsdump
85 85 86 86 87 89 90 90 90 90 90 91 91 91 92 92 93 94 95 95 96 96 96 97 98 98 98 99 99 99 101 101 101 102 102 103 103 104 104 106 106 107 107 107 108 108 109 109 109 110
. . . .
. . . .
. . . . 11.3.3. Recursos adicionais
11.4. RESTAURANDO UM SISTEMA DE ARQUIVO XFS A PARTIR DE BACKUP 11.4.1. Características da restauração do XFS a partir do backup
11.4.2. Restaurando um sistema de arquivo XFS a partir de backup com xfsrestore 11.4.3. Mensagens informativas na restauração de um backup XFS a partir de uma fita 11.4.4. Recursos adicionais
11.5. AUMENTANDO O TAMANHO DE UM SISTEMA DE ARQUIVO XFS 11.5.1. Aumentando o tamanho de um sistema de arquivo XFS com xfs_growfs 11.6. COMPARAÇÃO DAS FERRAMENTAS UTILIZADAS COM EXT4 E XFS CAPÍTULO 12. CONFIGURAÇÃO DO COMPORTAMENTO DE ERRO DO XFS
12.1. MANUSEIO DE ERROS CONFIGURÁVEL EM XFS
12.2. ARQUIVOS DE CONFIGURAÇÃO PARA CONDIÇÕES DE ERRO XFS ESPECÍFICAS E INDEFINIDAS 12.3. DEFINIÇÃO DO COMPORTAMENTO XFS PARA CONDIÇÕES ESPECÍFICAS
12.4. DEFININDO O COMPORTAMENTO DO XFS PARA CONDIÇÕES INDEFINIDAS 12.5. COMPORTAMENTO DE DESMONTAGEM DO XFS
CAPÍTULO 13. VERIFICAÇÃO E REPARO DE UM SISTEMA DE ARQUIVO
13.1. CENÁRIOS QUE REQUEREM UMA VERIFICAÇÃO DO SISTEMA DE ARQUIVO 13.2. POTENCIAIS EFEITOS COLATERAIS DO FSCK EM FUNCIONAMENTO 13.3. MECANISMOS DE TRATAMENTO DE ERROS EM XFS
Montagens não limpas Corrupção
13.4. VERIFICAÇÃO DE UM SISTEMA DE ARQUIVO XFS COM XFS_REPAIR 13.5. CONSERTO DE UM SISTEMA DE ARQUIVO XFS COM XFS_REPAIR 13.6. MECANISMOS DE TRATAMENTO DE ERROS EM EXT2, EXT3, E EXT4
13.7. VERIFICAÇÃO DE UM SISTEMA DE ARQUIVO EXT2, EXT3, OU EXT4 COM E2FSCK 13.8. CONSERTO DE UM SISTEMA DE ARQUIVO EXT2, EXT3, OU EXT4 COM E2FSCK CAPÍTULO 14. MONTAGEM DE SISTEMAS DE ARQUIVO
14.1. O MECANISMO DE MONTAGEM LINUX
14.2. LISTAGEM DOS SISTEMAS DE ARQUIVO ATUALMENTE MONTADOS 14.3. MONTAGEM DE UM SISTEMA DE ARQUIVO COM MONTAGEM 14.4. MOVENDO UM PONTO DE MONTAGEM
14.5. DESMONTANDO UM SISTEMA DE ARQUIVO COM UMOUNT 14.6. OPÇÕES COMUNS DE MONTAGEM
14.7. COMPARTILHAR UMA MONTAGEM EM VÁRIOS PONTOS DE MONTAGEM 14.7.1. Tipos de montagens compartilhadas
14.7.2. Criação de um duplicado de ponto de montagem privado 14.7.3. Criação de um duplicado de ponto de montagem compartilhado 14.7.4. Criação de um duplicado de ponto de montagem de escravos 14.7.5. Impedindo que um ponto de montagem seja duplicado 14.7.6. Informações relacionadas
14.8. MONTAGEM PERSISTENTE DE SISTEMAS DE ARQUIVO 14.8.1. O arquivo /etc/fstab
14.8.2. Adicionando um sistema de arquivo ao /etc/fstab
14.8.3. Montagem persistente de um sistema de arquivo usando os papéis do sistema RHEL
14.8.3.1. Exemplo Livro de reprodução possível para montar persistentemente um sistema de arquivo 14.8.3.2. Recursos adicionais
14.9. MONTAGEM DE SISTEMAS DE ARQUIVOS SOB DEMANDA 14.9.1. O serviço autofs
14.9.2. Os arquivos de configuração autofs O arquivo do mapa principal
Arquivos de mapas
111 111 111 111 113 113 113 113 114 116 116 116 117 117 118 119 119 120 120 120 120 121 122 123 124 124 126 126 126 127 128 128 129 130 130 131 132 133 134 135 135 135 136 137 137 138 138 138 138 139 139
. . . .
. . . .
. . . . O formato amd map
14.9.3. Configuração de pontos de montagem autofs
14.9.4. Montagem automática dos diretórios domésticos dos usuários do servidor NFS com o serviço autofs 14.9.5. Substituição ou aumento dos arquivos de configuração do site Autofs
14.9.6. Usando o LDAP para armazenar mapas de montadoras
14.10. DEFINIÇÃO DE PERMISSÕES SOMENTE LEITURA PARA O SISTEMA DE ARQUIVOS RAIZ 14.10.1. Arquivos e diretórios que sempre retêm permissões de escrita
14.10.2. Configuração do sistema de arquivo raiz para montagem com permissões somente leitura na inicialização
CAPÍTULO 15. LIMITANDO O USO DO ESPAÇO DE ARMAZENAMENTO COM COTAS 15.1. COTAS DE DISCOS
15.1.1. A ferramenta xfs_quota Recursos adicionais
15.2. GERENCIANDO QUOTAS DE DISCOS XFS
15.2.1. Gestão de quotas do sistema de arquivos em XFS 15.2.2. Habilitação de quotas de disco para XFS
15.2.3. Relatório de uso de XFS Pré-requisitos
Procedimento Recursos adicionais
15.2.4. Modificando os limites de quotas XFS Pré-requisitos
Procedimento Recursos adicionais
15.2.5. Estabelecendo os limites do projeto para XFS Procedimento
Recursos adicionais
15.3. GERENCIANDO QUOTAS DE DISCOS EXT3 E EXT4 15.3.1. Instalando a ferramenta de cota
15.3.2. Possibilitando o recurso de cota na criação do sistema de arquivos 15.3.3. Habilitação do recurso de cota nos sistemas de arquivo existentes 15.3.4. Possibilitando a aplicação de cotas
15.3.5. Atribuição de cotas por usuário 15.3.6. Atribuição de cotas por grupo 15.3.7. Atribuição de cotas por projeto
15.3.8. Estabelecendo o período de carência para limites suaves 15.3.9. Desligamento das quotas do sistema de arquivos 15.3.10. Relatórios sobre quotas de discos
CAPÍTULO 16. DESCARTANDO BLOCOS NÃO UTILIZADOS 16.1. OPERAÇÕES DE DESCARTE EM BLOCO
Requisitos
16.2. TIPOS DE OPERAÇÕES DE DESCARTE EM BLOCO Recomendações
16.3. EXECUÇÃO DE DESCARTE DE BLOCOS EM LOTE 16.4. PERMITINDO O DESCARTE EM BLOCO ONLINE
16.5. PERMITINDO O DESCARTE EM BLOCO ONLINE USANDO AS FUNÇÕES DO SISTEMA RHEL 16.5.1. Exemplo Livro de reprodução possível para permitir o descarte em bloco online
16.5.2. Recursos adicionais
16.6. POSSIBILITANDO O DESCARTE PERIÓDICO EM BLOCO
CAPÍTULO 17. GERENCIAMENTO DE ARMAZENAMENTO LOCAL EM CAMADAS COM O STRATIS
140 140 141 142 143 145 145 146 148 148 148 148 148 149 149 150 150 150 150 150 150 150 151 151 151 152 152 152 152 153 153 154 155 156 157 157 158 160 160 160 160 160 160 161 162 162 162 162 164
. . . .
. . . . 17.1. MONTAGEM DE SISTEMAS DE ARQUIVO STRATIS
17.1.1. O propósito e as características de Stratis 17.1.2. Componentes de um volume Stratis
17.1.3. Dispositivos de bloqueio utilizáveis com Stratis Dispositivos com suporte
Dispositivos sem suporte 17.1.4. Instalando o Stratis 17.1.5. Criação de um pool Stratis
17.1.6. Criação de um sistema de arquivo Stratis 17.1.7. Montagem de um sistema de arquivo Stratis
17.1.8. Montagem persistente de um sistema de arquivo Stratis 17.1.9. Informações relacionadas
17.2. AMPLIAÇÃO DE UM VOLUME STRATIS COM DISPOSITIVOS DE BLOQUEIO ADICIONAIS 17.2.1. Componentes de um volume Stratis
17.2.2. Adicionando dispositivos de blocos a uma piscina Stratis 17.2.3. Informações relacionadas
17.3. MONITORAMENTO DOS SISTEMAS DE ARQUIVO STRATIS 17.3.1. Tamanhos Stratis relatados por diferentes utilidades 17.3.2. Exibindo informações sobre os volumes do Stratis 17.3.3. Informações relacionadas
17.4. USANDO SNAPSHOTS EM SISTEMAS DE ARQUIVO STRATIS 17.4.1. Características dos snapshots de Stratis
17.4.2. Criando um instantâneo do Stratis
17.4.3. Acesso ao conteúdo de uma foto de Stratis
17.4.4. Revertendo um sistema de arquivo Stratis para um instantâneo anterior 17.4.5. Removendo uma foto do Stratis
17.4.6. Informações relacionadas
17.5. REMOÇÃO DOS SISTEMAS DE ARQUIVO STRATIS 17.5.1. Componentes de um volume Stratis
17.5.2. Remoção de um sistema de arquivo Stratis 17.5.3. Remoção de uma piscina Stratis
17.5.4. Informações relacionadas
CAPÍTULO 18. COMEÇANDO COM UM SISTEMA DE ARQUIVO EXT3 18.1. CARACTERÍSTICAS DE UM SISTEMA DE ARQUIVO EXT3 18.2. CRIAÇÃO DE UM SISTEMA DE ARQUIVO EXT3
18.3. MONTAGEM DE UM SISTEMA DE ARQUIVO EXT3
18.4. REDIMENSIONAMENTO DE UM SISTEMA DE ARQUIVO EXT3
18.5. CRIAÇÃO E MONTAGEM DE SISTEMAS DE ARQUIVO EXT3 USANDO FUNÇÕES DO SISTEMA RHEL 18.5.1. Exemplo Livro de reprodução possível para criar e montar um sistema de arquivo ext3
18.5.2. Recursos adicionais
CAPÍTULO 19. COMEÇANDO COM UM SISTEMA DE ARQUIVO EXT4 19.1. CARACTERÍSTICAS DE UM SISTEMA DE ARQUIVO EXT4 19.2. CRIAÇÃO DE UM SISTEMA DE ARQUIVO EXT4
19.3. MONTAGEM DE UM SISTEMA DE ARQUIVO EXT4
19.4. REDIMENSIONAMENTO DE UM SISTEMA DE ARQUIVO EXT4
19.5. CRIAÇÃO E MONTAGEM DE SISTEMAS DE ARQUIVO EXT4 USANDO FUNÇÕES DO SISTEMA RHEL 19.5.1. Exemplo Livro de reprodução possível para criar e montar um sistema de arquivo Ext4
19.6. COMPARAÇÃO DAS FERRAMENTAS UTILIZADAS COM EXT4 E XFS
164 164 164 165 165 166 166 166 168 169 170 171 171 171 172 172 172 172 173 173 173 174 174 174 175 176 176 176 176 177 178 178 180 180 180 181 182 183 183 184 185 185 185 187 187 189 189 190
TORNANDO O CÓDIGO ABERTO MAIS INCLUSIVO
A Red Hat tem o compromisso de substituir a linguagem problemática em nosso código, documentação e propriedades da web. Estamos começando com estes quatro termos: master, slave, blacklist e
whitelist. Por causa da enormidade deste esforço, estas mudanças serão implementadas gradualmente ao longo de vários lançamentos futuros. Para mais detalhes, veja a mensagem de nosso CTO Chris Wright.
FORNECENDO FEEDBACK SOBRE A DOCUMENTAÇÃO DA RED HAT
Agradecemos sua contribuição em nossa documentação. Por favor, diga-nos como podemos melhorá- la. Para fazer isso:
Para comentários simples sobre passagens específicas:
1. Certifique-se de que você está visualizando a documentação no formato Multi-page HTML.
Além disso, certifique-se de ver o botão Feedback no canto superior direito do documento.
2. Use o cursor do mouse para destacar a parte do texto que você deseja comentar.
3. Clique no pop-up Add Feedback que aparece abaixo do texto destacado.
4. Siga as instruções apresentadas.
Para enviar comentários mais complexos, crie um bilhete Bugzilla:
1. Ir para o site da Bugzilla.
2. Como Componente, use Documentation.
3. Preencha o campo Description com sua sugestão de melhoria. Inclua um link para a(s) parte(s) relevante(s) da documentação.
4. Clique em Submit Bug.
CAPÍTULO 1. VISÃO GERAL DOS SISTEMAS DE ARQUIVO DISPONÍVEIS
A escolha do sistema de arquivo apropriado para sua aplicação é uma decisão importante devido ao grande número de opções disponíveis e as contrapartidas envolvidas. Este capítulo descreve alguns dos sistemas de arquivo que são embarcados com o Red Hat Enterprise Linux 8 e fornece histórico e
recomendações sobre o sistema de arquivo correto para se adequar à sua aplicação.
1.1. TIPOS DE SISTEMAS DE ARQUIVO
O Red Hat Enterprise Linux 8 suporta uma variedade de sistemas de arquivo (FS). Diferentes tipos de sistemas de arquivo resolvem diferentes tipos de problemas, e seu uso é específico da aplicação. No nível mais geral, os sistemas de arquivo disponíveis podem ser agrupados nos seguintes tipos principais:
Tabela 1.1. Tipos de sistemas de arquivo e seus casos de uso
Tipo Sistema de arquivo Atributos e casos de uso
Disco ou FS local XFS XFS é o sistema de arquivo padrão na RHEL. Como ele apresenta os arquivos como extensões, é menos vulnerável à fragmentação do que ext4. A Red Hat recomenda implantar o XFS como seu sistema de arquivo local, a menos que haja razões específicas para fazer o contrário: por exemplo, compatibilidade ou casos de canto em torno do desempenho.
ext4 ext4 tem o benefício da longevidade no Linux.
Portanto, ela é suportada por quase todas as aplicações Linux. Na maioria dos casos, ele rivaliza com o XFS no desempenho. ext4 é comumente usado para diretórios domésticos.
Rede ou cliente-e- servidor FS
NFS Use NFS para compartilhar arquivos entre vários sistemas na mesma rede.
SMB Use SMB para compartilhamento de arquivos com sistemas Microsoft Windows.
Armazenamento compartilhado ou disco compartilhado FS
GFS2 O GFS2 fornece acesso compartilhado por escrito aos membros de um cluster de computação. A ênfase está na estabilidade e confiabilidade, com a experiência funcional de um sistema de arquivo local o mais possível. SAS Grid, Tibco MQ, IBM Websphere MQ, e Red Hat Active MQ foram implantados com sucesso no GFS2.
Gestão do volume FS Stratis (Pré-visualização tecnológica)
Stratis é um gerente de volume construído sobre uma combinação de XFS e LVM. O objetivo do Stratis é emular as capacidades oferecidas pelos sistemas de arquivo de gerenciamento de volume como Btrfs e ZFS. É possível construir esta pilha manualmente, mas o Stratis reduz a complexidade da configuração, implementa as melhores práticas e consolida as informações de erro.
Tipo Sistema de arquivo Atributos e casos de uso
1.2. SISTEMAS DE ARQUIVO LOCAIS
Sistemas de arquivos locais são sistemas de arquivos que rodam em um único servidor local e estão diretamente ligados ao armazenamento.
Por exemplo, um sistema de arquivo local é a única opção para discos SATA ou SAS internos, e é usado quando seu servidor tem controladores RAID de hardware internos com unidades locais. Os sistemas de arquivo locais também são os sistemas de arquivo mais comuns usados no armazenamento anexado ao SAN quando o dispositivo exportado no SAN não é compartilhado.
Todos os sistemas de arquivo locais são compatíveis com POSIX e são totalmente compatíveis com todas as versões suportadas do Red Hat Enterprise Linux. Os sistemas de arquivo compatíveis com POSIX fornecem suporte a um conjunto bem definido de chamadas de sistema, tais como read(), write() e seek().
Do ponto de vista do programador de aplicações, há relativamente poucas diferenças entre os sistemas de arquivo locais. As diferenças mais notáveis do ponto de vista do usuário estão relacionadas à
escalabilidade e desempenho. Ao considerar a escolha de um sistema de arquivo, considere o tamanho que o sistema de arquivo precisa ter, que características únicas ele deve ter e como ele funciona sob sua carga de trabalho.
Sistemas de arquivo locais disponíveis XFS
ext4
1.3. O SISTEMA DE ARQUIVO XFS
O XFS é um sistema de arquivo de diário de 64 bits altamente escalável, de alto desempenho, robusto e maduro que suporta arquivos muito grandes e sistemas de arquivo em um único host. É o sistema de arquivo padrão no Red Hat Enterprise Linux 8. O XFS foi originalmente desenvolvido no início dos anos 90 pela SGI e tem um longo histórico de rodar em servidores e arrays de armazenamento
extremamente grandes.
As características do XFS incluem:
Confiabilidade
Diário de Metadados, que garante a integridade do sistema de arquivo após uma falha do sistema, mantendo um registro das operações do sistema de arquivo que pode ser reproduzido quando o sistema é reiniciado e o sistema de arquivo recontado
reproduzido quando o sistema é reiniciado e o sistema de arquivo recontado Verificação extensiva da consistência dos metadados em tempo de execução Utilitários escaláveis e de reparo rápido
Diário de cotas. Isto evita a necessidade de longas verificações de consistência de cotas após uma queda.
Escalabilidade e desempenho
Tamanho do sistema de arquivo suportado até 1024 TiB
Capacidade de suportar um grande número de operações simultâneas Indexação B-tree para a escalabilidade da gestão do espaço livre Sofisticados algoritmos de leitura de metadados
Otimizações para a carga de trabalho de streaming de vídeo
Esquemas de alocação
Alocação baseada na extensão Políticas de alocação de listras Atraso na alocação
Pré-alocação de espaço
Inódios alocados dinamicamente
Outras características
Cópias de arquivos com base no Reflink (novo no Red Hat Enterprise Linux 8) Utilitários de backup e restauração bem integrados
Desfragmentação on-line
Sistema de arquivo on-line crescendo Recursos abrangentes de diagnóstico
Atributos estendidos (xattr). Isto permite que o sistema associe vários pares de nome/valor adicionais por arquivo.
Cotas de projetos ou diretórios. Isto permite restrições de cotas sobre uma árvore de diretórios.
Carimbos de tempo subseqüentes
Características de desempenho
O XFS tem um alto desempenho em grandes sistemas com cargas de trabalho empresariais. Um sistema grande é aquele com um número relativamente alto de CPUs, múltiplos HBAs e conexões com matrizes de disco externas. O XFS também tem um bom desempenho em sistemas menores que têm uma carga
de trabalho de E/S paralela e multi-tarefa.
O XFS tem um desempenho relativamente baixo para cargas de trabalho com um único threaded e metadata intensivo: por exemplo, uma carga de trabalho que cria ou elimina um grande número de pequenos arquivos em um único thread.
1.4. O SISTEMA DE ARQUIVO EXT4
O sistema de arquivo ext4 é a quarta geração da família do sistema de arquivo ext4. Era o sistema de arquivo default do Red Hat Enterprise Linux 6.
O driver ext4 pode ler e escrever em sistemas de arquivo ext2 e ext3, mas o formato do sistema de arquivo ext4 não é compatível com os drivers ext2 e ext3.
ext4 acrescenta várias características novas e melhoradas, como por exemplo:
Sistema de arquivo com suporte de até 50 TiB Metainformação baseada em extensão
Atraso na alocação
A soma de controle do diário Grande suporte de armazenamento
Os metadados baseados na extensão e os recursos de alocação atrasada proporcionam uma forma mais compacta e eficiente de rastrear o espaço utilizado em um sistema de arquivo. Estes recursos melhoram o desempenho do sistema de arquivos e reduzem o espaço consumido pelos metadados. A alocação atrasada permite que o sistema de arquivo adie a seleção do local permanente para os dados de usuários recém-escritos até que os dados sejam enviados para o disco. Isto permite um desempenho maior, pois pode permitir alocações maiores e mais contíguas, permitindo que o sistema de arquivo tome decisões com informações muito melhores.
O tempo de reparo do sistema de arquivos usando o utilitário fsck em ext4 é muito mais rápido do que em ext2 e ext3. Alguns reparos do sistema de arquivo têm demonstrado um aumento de até seis vezes no desempenho.
1.5. COMPARAÇÃO DE XFS E EXT4
XFS é o sistema de arquivo padrão na RHEL. Esta seção compara o uso e as características do XFS e ext4.
Comportamento de erro dos metadados
No ext4, você pode configurar o comportamento quando o sistema de arquivos encontra erros de metadados. O comportamento padrão é simplesmente continuar a operação. Quando o XFS encontra um erro irrecuperável de metadados, ele desliga o sistema de arquivos e retorna o erro EFSCORRUPTED.
Cotas
No ext4, você pode ativar cotas ao criar o sistema de arquivo ou mais tarde em um sistema de arquivo existente. Você pode então configurar a aplicação de cotas usando uma opção de montagem.
As cotas XFS não são uma opção remountable. Você deve ativar as cotas na montagem inicial.
A execução do comando quotacheck em um sistema de arquivos XFS não tem efeito. A primeira vez
A execução do comando quotacheck em um sistema de arquivos XFS não tem efeito. A primeira vez que você ativa a contabilização de cotas, o XFS verifica as cotas automaticamente.
Redimensionamento do sistema de arquivo
O XFS não tem utilidade para reduzir o tamanho de um sistema de arquivo. Você só pode aumentar o tamanho de um sistema de arquivo XFS. Em comparação, ext4 suporta tanto a ampliação quanto a redução do tamanho de um sistema de arquivo.
Números de inodo
O sistema de arquivo ext4 não suporta mais de 232 inodes.
O XFS aloca inodes dinamicamente. Um sistema de arquivo XFS não pode ficar sem inodes enquanto houver espaço livre no sistema de arquivo.
Certas aplicações não podem lidar corretamente com números de inode maiores que 232 em um sistema de arquivo XFS. Estas aplicações podem causar a falha de chamadas stat de 32 bits com o valor de retorno EOVERFLOW. O número de inode excede 232 sob as seguintes condições:
O sistema de arquivo é maior do que 1 TiB com nós de 256 bytes.
O sistema de arquivo é maior que 2 TiB com 512 bytes de inodes.
Se sua aplicação falhar com grandes números de inode, monte o sistema de arquivos XFS com a opção -o inode32 para impor números de inode abaixo de 232. Note que o uso do inode32 não afeta os inodes que já estão alocados com números de 64 bits.
IMPORTANTE
Faça not use a opção inode32 a menos que um ambiente específico o exija. A opção inode32 muda o comportamento de alocação. Como conseqüência, o erro ENOSPC pode ocorrer se não houver espaço disponível para alocar inodes nos blocos de disco inferiores.
1.6. ESCOLHENDO UM SISTEMA DE ARQUIVO LOCAL
Para escolher um sistema de arquivo que atenda às suas exigências de aplicação, você precisa entender o sistema alvo no qual você vai implantar o sistema de arquivo. Você pode usar as seguintes perguntas para informar sua decisão:
Você tem um servidor grande?
Você tem grandes exigências de armazenamento ou tem uma unidade SATA local e lenta?
Que tipo de carga de trabalho de E/S você espera que sua aplicação apresente?
Quais são seus requisitos de rendimento e latência?
Qual é a estabilidade de seu servidor e hardware de armazenamento?
Qual é o tamanho típico de seus arquivos e conjunto de dados?
Se o sistema falhar, quanto tempo de inatividade você pode sofrer?
Se tanto seu servidor quanto seu dispositivo de armazenamento forem grandes, o XFS é a melhor escolha. Mesmo com matrizes de armazenamento menores, o XFS funciona muito bem quando os tamanhos médios dos arquivos são grandes (por exemplo, centenas de megabytes em tamanho).
Se sua carga de trabalho existente tiver funcionado bem com ext4, ficar com ext4 deve proporcionar a você e suas aplicações um ambiente muito familiar.
O sistema de arquivo ext4 tende a ter melhor desempenho em sistemas que têm capacidade limitada de E/S. Ele tem melhor desempenho em largura de banda limitada (menos de 200MB/s) e até cerca de 1000 IOPS. Para qualquer coisa com maior capacidade, o XFS tende a ser mais rápido.
O XFS consome cerca do dobro da operação CPU por metadados em relação ao ext4, portanto, se você tiver uma carga de trabalho vinculada à CPU com pouca concorrência, então o ext4 será mais rápido. Em geral, ext4 é melhor se uma aplicação usa um único fio de leitura/gravação e arquivos pequenos, enquanto o XFS brilha quando uma aplicação usa vários fios de leitura/gravação e arquivos maiores.
Não se pode encolher um sistema de arquivos XFS. Se você precisa ser capaz de encolher o sistema de arquivo, considere o uso do ext4, que suporta o encolhimento off-line.
Em geral, a Red Hat recomenda que você use XFS a menos que você tenha um caso de uso específico para ext4. Você também deve medir o desempenho de sua aplicação específica em seu servidor e sistema de armazenamento alvo para ter certeza de que você escolheu o tipo apropriado de sistema de arquivo.
Tabela 1.2. Resumo das recomendações do sistema de arquivo local
Cenário Sistema de arquivo recomendado
Nenhum caso de uso especial XFS
Grande servidor XFS
Grandes dispositivos de armazenamento XFS
Arquivos grandes XFS
E/S com múltiplas roscas XFS
E/S com rosca única ext4
Capacidade limitada de E/S (menos de 1000 IOPS) ext4
Largura de banda limitada (menos de 200MB/s) ext4
Carga de trabalho vinculada à CPU ext4
Apoio ao encolhimento off-line ext4
1.7. SISTEMAS DE ARQUIVOS EM REDE
Os sistemas de arquivos em rede, também chamados de sistemas de arquivos cliente/servidor,
permitem que os sistemas clientes acessem arquivos que estão armazenados em um servidor
compartilhado. Isto torna possível para múltiplos usuários em múltiplos sistemas compartilhar arquivos e recursos de armazenamento.
Tais sistemas de arquivo são construídos a partir de um ou mais servidores que exportam um conjunto de sistemas de arquivo para um ou mais clientes. Os nós do cliente não têm acesso ao armazenamento em bloco subjacente, mas interagem com o armazenamento usando um protocolo que permite um melhor controle de acesso.
Sistemas de arquivos em rede disponíveis
O sistema de arquivo cliente/servidor mais comum para clientes RHEL é o sistema de arquivo NFS. A RHEL fornece tanto um componente servidor NFS para exportar um sistema de arquivo local através da rede quanto um cliente NFS para importar estes sistemas de arquivo.
A RHEL também inclui um cliente CIFS que suporta os populares servidores de arquivos Microsoft SMB para interoperabilidade com Windows. O servidor Samba do userspace fornece aos clientes Windows um serviço Microsoft SMB a partir de um servidor RHEL.
1.8. SISTEMAS DE ARQUIVOS DE ARMAZENAMENTO COMPARTILHADO
Sistemas de arquivo de armazenamento compartilhado, às vezes chamados de sistemas de arquivo de cluster, dão a cada servidor do cluster acesso direto a um dispositivo de bloco compartilhado através de uma rede de área de armazenamento local (SAN).
Comparação com sistemas de arquivos em rede
Como os sistemas de arquivo cliente/servidor, os sistemas de arquivo de armazenamento
compartilhado funcionam em um conjunto de servidores que são todos membros de um cluster. Ao contrário do NFS, no entanto, nenhum servidor único fornece acesso a dados ou metadados a outros membros: cada membro do cluster tem acesso direto ao mesmo dispositivo de armazenamento (o shared storage), e todos os nós de membros do cluster acessam o mesmo conjunto de arquivos.
Concorrência
A coerência do cache é fundamental em um sistema de arquivo agrupado para garantir a consistência e integridade dos dados. Deve haver uma única versão de todos os arquivos em um cluster visível a todos os nós dentro de um cluster. O sistema de arquivo deve impedir que os membros do cluster atualizem o mesmo bloco de armazenamento ao mesmo tempo e causem corrupção de dados. Para fazer isso, os sistemas de arquivos de armazenamento compartilhado usam um mecanismo de amplo bloqueio de cluster para arbitrar o acesso ao armazenamento como um mecanismo de controle de simultaneidade.
Por exemplo, antes de criar um novo arquivo ou escrever em um arquivo que é aberto em vários servidores, o componente do sistema de arquivo no servidor deve obter o bloqueio correto.
A exigência dos sistemas de arquivos de cluster é fornecer um serviço altamente disponível como um servidor web Apache. Qualquer membro do cluster terá uma visão totalmente coerente dos dados armazenados em seu sistema de arquivos em disco compartilhado, e todas as atualizações serão arbitradas corretamente pelos mecanismos de travamento.
Características de desempenho
Os sistemas de arquivo em disco compartilhado nem sempre funcionam tão bem quanto os sistemas de arquivo locais rodando no mesmo sistema, devido ao custo computacional da sobrecarga de
travamento. Sistemas de arquivos em disco compartilhado funcionam bem com cargas de trabalho onde cada nó escreve quase exclusivamente em um conjunto particular de arquivos que não são
compartilhados com outros nós ou onde um conjunto de arquivos é compartilhado de forma quase exclusivamente de leitura através de um conjunto de nós. Isto resulta em um mínimo de invalidação de cache entre nós e pode maximizar o desempenho.
A configuração de um sistema de arquivo em disco compartilhado é complexa, e ajustar uma aplicação para ter um bom desempenho em um sistema de arquivo em disco compartilhado pode ser um desafio.
Sistemas de arquivos de armazenamento compartilhado disponíveis
O Red Hat Enterprise Linux fornece o sistema de arquivo GFS2. O GFS2 vem bem integrado com o Red Hat Enterprise Linux High Availability Add-On e o Resilient Storage Add-On.
O Red Hat Enterprise Linux suporta GFS2 em clusters que variam em tamanho de 2 a 16 nós.
1.9. ESCOLHENDO ENTRE SISTEMAS DE ARQUIVOS EM REDE E DE ARMAZENAMENTO COMPARTILHADO
Ao escolher entre sistemas de arquivos em rede e de armazenamento compartilhado, considere os seguintes pontos
Os sistemas de arquivos de rede baseados em NFS são uma escolha extremamente comum e popular para ambientes que fornecem servidores NFS.
Os sistemas de arquivos de rede podem ser implantados utilizando tecnologias de rede de muito alto desempenho como Infiniband ou 10 Gigabit Ethernet. Isto significa que você não deve recorrer a sistemas de arquivos de armazenamento compartilhado apenas para obter largura de banda bruta para seu armazenamento. Se a velocidade de acesso é de suma importância, então use NFS para exportar um sistema de arquivo local como o XFS.
Sistemas de arquivos de armazenamento compartilhado não são fáceis de configurar ou manter, portanto, você deve implantá-los somente quando não puder fornecer sua disponibilidade necessária com sistemas de arquivos locais ou em rede.
Um sistema de arquivo de armazenamento compartilhado em um ambiente agrupado ajuda a reduzir o tempo de parada, eliminando as etapas necessárias para a desmontagem e montagem que precisam ser feitas durante um típico cenário de falha envolvendo a relocação de um serviço de alta disponibilidade.
A Red Hat recomenda que você utilize sistemas de arquivo em rede, a menos que você tenha um caso de uso específico para sistemas de arquivo de armazenamento compartilhado. Use sistemas de arquivo de armazenamento compartilhado principalmente para implantações que precisam fornecer serviços de alta disponibilidade com tempo mínimo de inatividade e com requisitos rigorosos de nível de serviço.
1.10. SISTEMAS DE ARQUIVOS DE GERENCIAMENTO DE VOLUME
Os sistemas de arquivo de gerenciamento de volume integram toda a pilha de armazenamento para fins de simplicidade e otimização na pilha.
Sistemas de arquivos de gerenciamento de volume disponíveis
O Red Hat Enterprise Linux 8 fornece o gerenciador de volume Stratis como uma prévia de tecnologia. Stratis usa XFS para a camada de sistema de arquivo e o integra com LVM, Device Mapper, e outros componentes.
Stratis foi lançado pela primeira vez no Red Hat Enterprise Linux 8.0. Ele foi concebido para preencher a lacuna criada quando a Red Hat depreciou o Btrfs. Stratis 1.0 é um gerenciador de volume intuitivo, baseado em linha de comando, que pode realizar operações significativas de gerenciamento de armazenamento enquanto esconde a complexidade do usuário:
Gerenciamento de volume
Criação de pool
Piscinas de armazenagem finas Instantâneos
Cache de leitura automatizado
Stratis oferece características poderosas, mas atualmente carece de certas capacidades de outras ofertas com as quais poderia ser comparado, tais como Btrfs ou ZFS. Mais notavelmente, ele não suporta CRCs com autocura.
CAPÍTULO 2. GERENCIAMENTO DO ARMAZENAMENTO LOCAL USANDO AS FUNÇÕES DO SISTEMA RHEL
Para gerenciar LVM e sistemas de arquivos locais (FS) usando o Ansible, você pode usar a função storage, que é uma das funções do Sistema RHEL disponível no RHEL 8.
O uso da função storage permite automatizar a administração de sistemas de arquivos em discos e volumes lógicos em múltiplas máquinas e em todas as versões da RHEL, começando com a RHEL 7.7.
Para mais informações sobre os papéis do Sistema RHEL e como aplicá-los, consulte Introdução aos papéis do Sistema RHEL.
2.1. INTRODUÇÃO À FUNÇÃO DE ARMAZENAMENTO
A função storage pode administrar:
Sistemas de arquivos em discos que não foram particionados
Grupos completos de volumes LVM incluindo seus volumes lógicos e sistemas de arquivo Com o papel storage você pode realizar as seguintes tarefas:
Criar um sistema de arquivo Remover um sistema de arquivo Montar um sistema de arquivo Desmontar um sistema de arquivo Criar grupos de volume LVM Remover grupos de volume LVM Criar volumes lógicos
Remover volumes lógicos Criar volumes RAID Remover volumes RAID Criar pools LVM com RAID
Remover as piscinas LVM com RAID
2.2. PARÂMETROS QUE IDENTIFICAM UM DISPOSITIVO DE
ARMAZENAMENTO NO PAPEL DO SISTEMA DE ARMAZENAMENTO
Sua configuração de funções storage afeta apenas os sistemas de arquivos, volumes e pools que você lista nas seguintes variáveis.
storage_volumes
Lista de sistemas de arquivos em todos os discos não particionados a serem gerenciados.
Atualmente, as partições não têm suporte.
storage_pools
Lista de piscinas a serem administradas.
Atualmente, o único tipo de piscina suportada é a LVM. Com LVM, os pools representam grupos de volume (VGs). Sob cada pool há uma lista de volumes a serem gerenciados pela função. Com o LVM, cada volume corresponde a um volume lógico (LV) com um sistema de arquivo.
2.3. EXEMPLO LIVRO DE REPRODUÇÃO POSSÍVEL PARA CRIAR UM SISTEMA DE ARQUIVO XFS EM UM DISPOSITIVO DE BLOCO
Esta seção fornece um exemplo de um livro de brincadeiras possível. Este playbook aplica o papel storage para criar um sistema de arquivos XFS em um dispositivo de bloco usando os parâmetros padrão.
ATENÇÃO
A função storage pode criar um sistema de arquivo somente em um disco não particionado, inteiro ou em um volume lógico (LV). Ele não pode criar o sistema de arquivo em uma partição.
Exemplo 2.1. Um playbook que cria XFS em /dev/sdb ---
- hosts: all vars:
storage_volumes:
- name: barefs type: disk disks:
- sdb fs_type: xfs roles:
- rhel-system-roles.storage
O nome do volume (barefs no exemplo) é atualmente arbitrária. A função storage identifica o volume pelo dispositivo de disco listado sob o atributo disks:.
Você pode omitir a linha fs_type: xfs porque XFS é o sistema de arquivo padrão no RHEL 8.
Para criar o sistema de arquivo em um LV, forneça a configuração LVM sob o atributo disks:, incluindo o grupo de volume envolvente. Para detalhes, veja Exemplo Livro de exemplo para gerenciar volumes lógicos.
Não forneça o caminho para o dispositivo LV.
Recursos adicionais
Para detalhes sobre os parâmetros utilizados na função do sistema storage, consulte o arquivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.
2.4. EXEMPLO LIVRO DE REPRODUÇÃO POSSÍVEL PARA MONTAR PERSISTENTEMENTE UM SISTEMA DE ARQUIVO
Esta seção fornece um exemplo de um livro de brincadeiras possível. Este playbook aplica o papel storage para montar imediata e persistentemente um sistema de arquivos XFS.
Exemplo 2.2. Um playbook que monta um sistema de arquivo em /dev/sdb para /mnt/dados ---
- hosts: all vars:
storage_volumes:
- name: barefs type: disk disks:
- sdb fs_type: xfs
mount_point: /mnt/data roles:
- rhel-system-roles.storage
Este playbook adiciona o sistema de arquivo ao arquivo /etc/fstab, e monta o sistema de arquivo imediatamente.
Se o sistema de arquivo no dispositivo /dev/sdb ou o diretório de pontos de montagem não existir, o playbook os cria.
Recursos adicionais
Para detalhes sobre os parâmetros utilizados na função do sistema storage, consulte o arquivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.
2.5. EXEMPLO LIVRO DE EXERCÍCIOS POSSÍVEL PARA GERENCIAR VOLUMES LÓGICOS
Esta seção fornece um exemplo de um livro de brincadeiras possível. Este playbook aplica o papel storage para criar um volume lógico LVM em um grupo de volumes.
Exemplo 2.3. Um playbook que cria um volume lógico mylv no grupo de volume myvg - hosts: all
vars:
storage_pools:
- name: myvg disks:
- sda - sdb - sdc volumes:
- name: mylv size: 2G fs_type: ext4 mount_point: /mnt roles:
- rhel-system-roles.storage
O grupo de volume myvg é composto pelos seguintes discos:
/dev/sda /dev/sdb /dev/sdc
Se o grupo de volume myvg já existe, o playbook adiciona o volume lógico ao grupo de volume.
Se o grupo de volume myvg não existe, o playbook o cria.
O playbook cria um sistema de arquivo Ext4 no volume lógico mylv e monta persistentemente o sistema de arquivo em /mnt.
Recursos adicionais
Para detalhes sobre os parâmetros utilizados na função do sistema storage, consulte o arquivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.
2.6. EXEMPLO LIVRO DE REPRODUÇÃO POSSÍVEL PARA PERMITIR O DESCARTE EM BLOCO ONLINE
Esta seção fornece um exemplo de um livro de brincadeiras possível. Este playbook aplica o papel storage para montar um sistema de arquivo XFS com o descarte de blocos on-line habilitado.
Exemplo 2.4. Um playbook que permite o descarte de blocos online em /mnt/dados/
---
- hosts: all vars:
storage_volumes:
- name: barefs type: disk disks:
- sdb fs_type: xfs
mount_point: /mnt/data mount_options: discard roles:
- rhel-system-roles.storage
Recursos adicionais
Este playbook também realiza todas as operações do exemplo de montagem persistente descrito em Seção 2.4, “Exemplo Livro de reprodução possível para montar persistentemente um sistema de arquivo”.
Para detalhes sobre os parâmetros utilizados na função do sistema storage, consulte o arquivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.
2.7. EXEMPLO LIVRO DE REPRODUÇÃO POSSÍVEL PARA CRIAR E MONTAR UM SISTEMA DE ARQUIVO EXT4
Esta seção fornece um exemplo de um livro de brincadeiras possível. Este playbook aplica o papel storage para criar e montar um sistema de arquivos Ext4.
Exemplo 2.5. Um playbook que cria Ext4 em /dev/sdb e o monta em /mnt/dados ---
- hosts: all vars:
storage_volumes:
- name: barefs type: disk disks:
- sdb fs_type: ext4
fs_label: label-name mount_point: /mnt/data roles:
- rhel-system-roles.storage
O playbook cria o sistema de arquivos no disco /dev/sdb.
O playbook monta persistentemente o sistema de arquivo no /mnt/data diretório.
A etiqueta do sistema de arquivo é label-name.
Recursos adicionais
Para detalhes sobre os parâmetros utilizados na função do sistema storage, consulte o arquivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.
2.8. EXEMPLO LIVRO DE REPRODUÇÃO POSSÍVEL PARA CRIAR E MONTAR UM SISTEMA DE ARQUIVO EXT3
Esta seção fornece um exemplo de um livro de brincadeiras possível. Este playbook aplica o papel storage para criar e montar um sistema de arquivos Ext3.
Exemplo 2.6. Um playbook que cria Ext3 em /dev/sdb e o monta em /mnt/dados ---
- hosts: all vars:
storage_volumes:
- name: barefs type: disk disks:
- sdb fs_type: ext3
fs_label: label-name mount_point: /mnt/data roles:
- rhel-system-roles.storage
O playbook cria o sistema de arquivos no disco /dev/sdb.
O playbook monta persistentemente o sistema de arquivo no /mnt/data diretório.
A etiqueta do sistema de arquivo é label-name.
Recursos adicionais
Para detalhes sobre os parâmetros utilizados na função do sistema storage, consulte o arquivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.
2.9. CONFIGURAÇÃO DE UM VOLUME RAID UTILIZANDO A FUNÇÃO DO SISTEMA DE ARMAZENAMENTO
Com o Sistema Função storage, você pode configurar um volume RAID na RHEL usando a Plataforma de Automação Possível Red Hat Ansible Automation. Nesta seção, você aprenderá como configurar um livro de jogo possível com os parâmetros disponíveis para configurar um volume RAID de acordo com suas necessidades.
Pré-requisitos
Você tem o Red Hat Ansible Engine instalado no sistema a partir do qual você deseja executar o playbook.
NOTA
Você não precisa ter a Plataforma de Automação Possível da Red Hat instalada nos sistemas nos quais você deseja implantar a solução storage.
Você tem o pacote rhel-system-roles instalado no sistema a partir do qual você deseja executar o playbook.
Você tem um arquivo de inventário detalhando os sistemas nos quais você deseja implantar um volume RAID usando o sistema storage Função do sistema.
Procedimento
1. Criar um novo playbook.yml arquivo com o seguinte conteúdo:
- hosts: all vars:
storage_safe_mode: false
storage_volumes:
- name: data type: raid
disks: [sdd, sde, sdf, sdg]
raid_level: raid0
raid_chunk_size: 32 KiB mount_point: /mnt/data state: present
roles:
- name: rhel-system-roles.storage
ATENÇÃO
Os nomes dos dispositivos podem mudar em certas circunstâncias; por exemplo, quando você adiciona um novo disco a um sistema. Portanto, para evitar a perda de dados, não recomendamos o uso de nomes de disco específicos no livro de reprodução.
2. Opcional. Verificar a sintaxe do playbook.
# ansible-playbook --syntax-check playbook.yml 3. Execute o playbook em seu arquivo de inventário:
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
Recursos adicionais
Para mais informações sobre o RAID, consulte Gerenciando RAID.
Para detalhes sobre os parâmetros utilizados na função do sistema de armazenamento, consulte o arquivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.
2.10. CONFIGURAÇÃO DE UM POOL LVM COM RAID UTILIZANDO A FUNÇÃO DE SISTEMA DE ARMAZENAMENTO
Com o Sistema Função storage, você pode configurar um pool LVM com RAID na RHEL usando a Plataforma de Automação Possível da Red Hat. Nesta seção você aprenderá como configurar um playbook Ansible com os parâmetros disponíveis para configurar um pool LVM com RAID.
Pré-requisitos
Você tem o Red Hat Ansible Engine instalado no sistema a partir do qual você deseja executar o playbook.
NOTA
NOTA
Você não precisa ter a Plataforma de Automação Possível da Red Hat instalada nos sistemas nos quais você deseja implantar a solução storage.
Você tem o pacote rhel-system-roles instalado no sistema a partir do qual você deseja executar o playbook.
Você tem um arquivo de inventário detalhando os sistemas nos quais você deseja configurar um pool LVM com RAID usando o sistema storage Função do sistema.
Procedimento
1. Criar um novo playbook.yml arquivo com o seguinte conteúdo:
- hosts: all vars:
storage_safe_mode: false storage_pools:
- name: my_pool type: lvm disks: [sdh, sdi]
raid_level: raid1 volumes:
- name: my_pool size: "1 GiB"
mount_point: "/mnt/app/shared"
fs_type: xfs state: present roles:
- name: rhel-system-roles.storage
NOTA
Para criar um pool LVM com RAID, você deve especificar o tipo de RAID usando o parâmetro raid_level.
2. Opcional. Verificar a sintaxe do playbook.
# ansible-playbook --syntax-check playbook.yml 3. Execute o playbook em seu arquivo de inventário:
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
Recursos adicionais
Para mais informações sobre o RAID, consulte Gerenciando RAID.
Para detalhes sobre os parâmetros utilizados na função do sistema de armazenamento, consulte o arquivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.
2.11. CRIAÇÃO DE UM VOLUME CODIFICADO LUKS USANDO A FUNÇÃO DE ARMAZENAMENTO
Você pode usar o papel storage para criar e configurar um volume criptografado com LUKS, executando um livro de brincadeiras Ansible playbook.
Pré-requisitos
Você tem o Red Hat Ansible Engine instalado no sistema a partir do qual você deseja executar o playbook.
NOTA
Você não precisa ter a Plataforma de Automação Possível da Red Hat instalada nos sistemas nos quais você deseja criar o volume.
Você tem o pacote rhel-system-roles instalado no controlador Ansible.
Você tem um arquivo de inventário detalhando os sistemas nos quais você deseja implantar um volume codificado LUKS usando a função de sistema de armazenamento.
Procedimento
1. Criar um novo playbook.yml arquivo com o seguinte conteúdo:
- hosts: all vars:
storage_volumes:
- name: barefs type: disk disks:
- sdb fs_type: xfs
fs_label: label-name mount_point: /mnt/data encryption: true
encryption_password: your-password roles:
- rhel-system-roles.storage
2. Opcional. Verificar a sintaxe do playbook:
# ansible-playbook --syntax-check playbook.yml 3. Execute o playbook em seu arquivo de inventário:
# ansible-playbook -i inventory.file /path/to/file/playbook.yml
Recursos adicionais
Para mais informações sobre a LUKS, veja 17. Criptografando dispositivos de blocos usando LUKS...
Para detalhes sobre os parâmetros utilizados na função do sistema storage, consulte o arquivo
Para detalhes sobre os parâmetros utilizados na função do sistema storage, consulte o arquivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.
Recursos adicionais
Para mais informações, instale o pacote rhel-system-roles e veja os seguintes diretórios:
/usr/share/doc/rhel-system-roles/storage/
/usr/share/ansible/roles/rhel-system-roles.storage/
CAPÍTULO 3. MONTAGEM DE AÇÕES DA NFS
Como administrador do sistema, você pode montar ações NFS remotas em seu sistema para acessar dados compartilhados.
3.1. INTRODUÇÃO AO NFS
Esta seção explica os conceitos básicos do serviço NFS.
Um Sistema de Arquivo em Rede (NFS) permite que hosts remotos montem sistemas de arquivo em rede e interajam com esses sistemas de arquivo como se fossem montados localmente. Isto permite a consolidação de recursos em servidores centralizados na rede.
O servidor NFS se refere ao arquivo de configuração /etc/exports para determinar se o cliente tem permissão para acessar qualquer sistema de arquivo exportado. Uma vez verificadas, todas as operações de arquivo e diretório estão disponíveis para o usuário.
3.2. VERSÕES NFS SUPORTADAS
Esta seção lista versões do NFS suportadas no Red Hat Enterprise Linux e suas características.
Atualmente, o Red Hat Enterprise Linux 8 suporta as seguintes versões principais do NFS:
O NFS versão 3 (NFSv3) suporta escritas assíncronas seguras e é mais robusto no manuseio de erros do que o NFSv2 anterior; ele também suporta tamanhos de arquivos de 64 bits e offsets, permitindo aos clientes acessar mais de 2 GB de dados de arquivos.
O NFS versão 4 (NFSv4) funciona através de firewalls e na Internet, não requer mais um serviço rpcbind, suporta Listas de Controle de Acesso (ACLs), e utiliza operações estaduais.
O NFS versão 2 (NFSv2) não é mais suportado pela Red Hat.
Versão padrão da NFS
A versão default do NFS no Red Hat Enterprise Linux 8 é 4.2. Clientes NFS tentam montar usando o NFSv4.2 por default, e voltam ao NFSv4.1 quando o servidor não suporta o NFSv4.2. A montagem posteriormente cai de volta para o NFSv4.0 e depois para o NFSv3.
Características das versões menores do NFS
A seguir estão as características do NFSv4.2 no Red Hat Enterprise Linux 8:
Cópia do lado do servidor
Permite que o cliente NFS copie dados com eficiência sem desperdiçar recursos da rede usando a chamada do sistema copy_file_range().
Arquivos esparsos
Permite que os arquivos tenham um ou mais holes, que são blocos de dados não alocados ou não inicializados, consistindo apenas em zeros. A operação lseek() no NFSv4.2 suporta seek_hole() e seek_data(), o que permite às aplicações mapear a localização de furos no arquivo esparso.
Reserva de espaço
Permite que os servidores de armazenamento reservem espaço livre, o que proíbe que os servidores fiquem sem espaço. O NFSv4.2 suporta a operação allocate() para reservar espaço, a operação deallocate() para espaço sem reserva e a operação fallocate() para pré-alocar ou desalocar espaço em um arquivo.
Rotulado NFS
Impõe direitos de acesso aos dados e permite etiquetas SELinux entre um cliente e um servidor para arquivos individuais em um sistema de arquivos NFS.
Melhorias de layout
Fornece a operação layoutstats(), que permite que alguns servidores Parallel NFS (pNFS) coletem estatísticas de melhor desempenho.
A seguir estão as características do NFSv4.1:
Aumenta o desempenho e a segurança da rede, e também inclui suporte do lado do cliente para o pNFS.
Não é mais necessária uma conexão TCP separada para callbacks, o que permite que um servidor NFS conceda delegações mesmo quando não pode contatar o cliente: por exemplo, quando NAT ou um firewall interfere.
Fornece exatamente uma vez a semântica (exceto para operações de reinício), evitando um problema anterior pelo qual certas operações às vezes retornavam um resultado impreciso se uma resposta fosse perdida e a operação fosse enviada duas vezes.
3.3. SERVIÇOS REQUERIDOS PELA NFS
Esta seção lista os serviços de sistema que são necessários para executar um servidor NFS ou montar ações NFS. O Red Hat Enterprise Linux inicia estes serviços automaticamente.
O Red Hat Enterprise Linux usa uma combinação de suporte em nível de kernel e processos de serviço para fornecer compartilhamento de arquivos NFS. Todas as versões NFS dependem de Remote Procedure Calls (RPC) entre clientes e servidores. Para compartilhar ou montar sistemas de arquivo NFS, os seguintes serviços trabalham em conjunto, dependendo de qual versão do NFS é implementada:
nfsd
O módulo de kernel do servidor NFS que atende solicitações de sistemas de arquivos NFS compartilhados.
rpcbind
Aceita reservas portuárias dos serviços locais de RPC. Estes portos são então disponibilizados (ou anunciados) para que os serviços de RPCs remotos correspondentes possam acessá-los. O serviço rpcbind responde às solicitações de serviços de RPC e estabelece conexões com o serviço de RPC solicitado. Isto não é usado com o NFSv4.
rpc.mountd
Este processo é usado por um servidor NFS para processar solicitações de clientes NFSv3 em MOUNT. Ele verifica se o compartilhamento NFS solicitado é atualmente exportado pelo servidor NFS, e se o cliente tem permissão para acessá-lo. Se a solicitação de montagem for permitida, o serviço nfs-mountd responde com um status de Sucesso e fornece o File-Handle para este compartilhamento NFS de volta para o cliente NFS.
rpc.nfsd
Este processo permite a definição de versões e protocolos NFS explícitos que o servidor anuncia. Ele trabalha com o kernel Linux para atender às demandas dinâmicas dos clientes NFS, tais como
fornecer threads de servidor cada vez que um cliente NFS se conecta. Este processo corresponde ao serviço nfs-server.
lockd
Esta é uma linha de kernel que roda tanto em clientes quanto em servidores. Ele implementa o protocolo Network Lock Manager (NLM), que permite aos clientes NFSv3 bloquear arquivos no servidor. Ele é iniciado automaticamente sempre que o servidor NFS é executado e sempre que um
sistema de arquivos NFS é montado.
rpc.statd
Este processo implementa o protocolo Network Status Monitor (NSM) RPC, que notifica os clientes NFS quando um servidor NFS é reiniciado sem ser derrubado graciosamente. O serviço rpc-statd é iniciado automaticamente pelo serviço nfs-server, e não requer configuração do usuário. Isto não é usado com o NFSv4.
rpc.rquotad
Este processo fornece informações de cota de usuário para usuários remotos. O serviço rpc-rquotad é iniciado automaticamente pelo serviço nfs-server e não requer configuração do usuário.
rpc.idmapd
Este processo fornece upcalls de cliente e servidor NFSv4, que mapeiam entre os nomes NFSv4 on- the-wire (strings sob a forma de user@domain) e UIDs e GIDs locais. Para que idmapd funcione com NFSv4, o arquivo /etc/idmapd.conf deve ser configurado. No mínimo, deve ser especificado o parâmetro Domain, que define o domínio de mapeamento do NFSv4. Se o domínio de mapeamento do NFSv4 for o mesmo que o nome de domínio DNS, este parâmetro pode ser ignorado. O cliente e o servidor devem concordar sobre o domínio de mapeamento do NFSv4 para que o mapeamento de ID funcione corretamente.
Somente o servidor NFSv4 usa rpc.idmapd, que é iniciado pelo serviço nfs-idmapd. O cliente NFSv4 usa o utilitário nfsidmap baseado no keyring, que é chamado pelo kernel on-demand para realizar o mapeamento de ID. Se houver um problema com nfsidmap, o cliente volta a usar rpc.idmapd.
Os serviços de RPC com NFSv4
Os protocolos de montagem e travamento foram incorporados ao protocolo NFSv4. O servidor também ouve na conhecida porta TCP 2049. Como tal, o NFSv4 não precisa interagir com rpcbind, lockd, e rpc-statd serviços. O serviço nfs-mountd ainda é necessário no servidor NFS para configurar as exportações, mas não está envolvido em nenhuma operação de "over-the-wire".
Recursos adicionais
Para configurar um servidor somente NFSv4, que não requer rpcbind, ver Seção 4.14,
“Configuração de um servidor NFSv4 apenas”.
3.4. FORMATOS DO NOME DO HOST NFS
Esta seção descreve diferentes formatos que você pode usar para especificar um host ao montar ou exportar uma ação NFS.
Você pode especificar o anfitrião nos seguintes formatos:
Máquina única
Qualquer uma das seguintes opções:
Um nome de domínio totalmente qualificado (que pode ser resolvido pelo servidor) Nome do host (que pode ser resolvido pelo servidor)
Um endereço IP.
Redes IP
Qualquer um dos seguintes formatos é válido:
a.b.c.d/zonde a.b.c.d é a rede e z é o número de bits na máscara de rede; por exemplo 192.168.0.0/24.
a.b.c.d/netmaskonde a.b.c.d é a rede e netmask é a máscara de rede; por exemplo, 192.168.100.8/255.255.255.0.
Netgroups
O @group-name formato , onde group-name é o nome do NIS netgroup.
3.5. INSTALANDO O NFS
Este procedimento instala todos os pacotes necessários para montar ou exportar ações da NFS.
Procedimento
Instale o pacote nfs-utils:
# yum instalar nfs-utils
3.6. DESCOBRINDO AS EXPORTAÇÕES DA NFS
Este procedimento descobre quais sistemas de arquivo um determinado servidor NFSv3 ou NFSv4 exporta.
Procedimento
Com qualquer servidor que suporte NFSv3, use o utilitário showmount:
$ showmount --exports my-server Export list for my-server
/exports/foo /exports/bar
Com qualquer servidor que suporte NFSv4, monte o diretório raiz e olhe ao redor:
# mount my-server:/ /mnt/
# ls /mnt/
exports
# ls /mnt/exports/
foo bar
Em servidores que suportam tanto NFSv4 quanto NFSv3, ambos os métodos funcionam e dão os mesmos resultados.
Recursos adicionais
A página do homem showmount(8).
3.7. MONTAGEM DE UM COMPARTILHAMENTO NFS COM MONTAGEM
Este procedimento monta uma parte NFS exportada de um servidor usando o utilitário mount.
Procedimento
Para montar um compartilhamento NFS, use o seguinte comando:
# montagem -t nfs -o options host:/remote/export /local/directory Este comando utiliza as seguintes variáveis:
options
Uma lista delimitada por vírgulas de opções de montagem.
host
O nome do host, endereço IP, ou nome de domínio totalmente qualificado do servidor que exporta o sistema de arquivos que você deseja montar.
/remote/export
O sistema de arquivo ou diretório sendo exportado do servidor, ou seja, o diretório que você deseja montar.
/local/directory
O local do cliente onde /remote/export é montado.
Recursos adicionais
Seção 3.8, “Opções comuns de montagem NFS”
Seção 3.4, “Formatos do nome do host NFS”
Seção 14.3, “Montagem de um sistema de arquivo com montagem”
A página do homem mount(8)
3.8. OPÇÕES COMUNS DE MONTAGEM NFS
Esta seção lista as opções comumente usadas na montagem de ações NFS. Estas opções podem ser usadas com comandos de montagem manual, configurações /etc/fstab, e autofs.
lookupcache=mode
Especifica como o kernel deve gerenciar seu cache de entradas de diretório para um determinado ponto de montagem. Argumentos válidos para mode são all, none, ou positive.
nfsvers=version
Especifica qual versão do protocolo NFS deve ser usada, onde version é 3, 4, 4.0, 4.1, ou 4.2. Isto é útil para hosts que rodam vários servidores NFS, ou para desativar a re-instalação de uma montagem com versões inferiores. Se nenhuma versão for especificada, o NFS usa a versão mais alta suportada pelo kernel e o utilitário mount.
A opção vers é idêntica a nfsvers, e está incluída neste release por razões de compatibilidade.
noacl
Desliga todo o processamento de ACL. Isto pode ser necessário ao fazer interface com versões mais
Desliga todo o processamento de ACL. Isto pode ser necessário ao fazer interface com versões mais antigas do Red Hat Enterprise Linux, Red Hat Linux ou Solaris, porque a tecnologia ACL mais
recente não é compatível com sistemas mais antigos.
nolock
Desativa o bloqueio de arquivos. Esta configuração é às vezes necessária quando se conecta a servidores NFS muito antigos.
noexec
Impede a execução de binários em sistemas de arquivos montados. Isto é útil se o sistema estiver montando um sistema de arquivo não-Linux contendo binários incompatíveis.
nosuid
Desativa os bits set-user-identifier e set-group-identifier. Isto impede que usuários remotos ganhem privilégios mais altos ao executar um programa setuid.
port=num
Especifica o valor numérico da porta do servidor NFS. Se num é 0 (o valor padrão), então mount consulta o serviço rpcbind no host remoto para que o número da porta seja utilizado. Se o serviço NFS no host remoto não estiver registrado com seu serviço rpcbind, o número padrão da porta NFS do TCP 2049 é usado em seu lugar.
rsize=num e wsize=num
Estas opções definem o número máximo de bytes a serem transferidos em uma única operação de leitura ou escrita NFS.
Não há valor padrão fixo para rsize e wsize. Por padrão, o NFS usa o maior valor possível tanto para o servidor quanto para o suporte ao cliente. No Red Hat Enterprise Linux 8, o cliente e o servidor têm um máximo de 1.048.576 bytes. Para mais detalhes, veja a seção Quais são os valores default e máximo para rsize e wsize com montagens do NFS? Artigo do KBase.
sec=flavors
Sabores de segurança a serem usados para acessar arquivos na exportação montada. O flavors é uma lista separada por dois pontos de um ou mais sabores de segurança.
Por padrão, o cliente tenta encontrar um sabor de segurança que tanto o cliente quanto o servidor suportam. Se o servidor não suportar nenhum dos sabores selecionados, a operação de montagem falha.
Sabores disponíveis:
sec=sys utiliza UNIX UIDs e GIDs locais. Estes usam AUTH_SYS para autenticar as operações NFS.
sec=krb5 usa Kerberos V5 em vez de UIDs e GIDs UNIX locais para autenticar os usuários.
sec=krb5i utiliza o Kerberos V5 para autenticação do usuário e realiza a verificação de integridade das operações NFS utilizando checksums seguros para evitar a adulteração de dados.
sec=krb5p utiliza o Kerberos V5 para autenticação do usuário, verificação de integridade e criptografia do tráfego NFS para evitar o farejamento do tráfego. Esta é a configuração mais segura, mas também envolve a maior sobrecarga de desempenho.
tcp
Instrui o suporte NFS a usar o protocolo TCP.
Recursos adicionais
