Antes de instalar e configurar o GFS2, observe as seguintes características-chave de seus sistemas de arquivo GFS2:

Tabela 1.1, “GFS2 Limites de suporte” resume o tamanho máximo atual do sistema de arquivo e o número de nós que o GFS2 suporta.

O GFS2 é baseado em uma arquitetura de 64 bits, que teoricamente pode acomodar um sistema de arquivos 8 EB. Se seu sistema requer sistemas de arquivo GFS2 maiores do que os atualmente suportados, entre em contato com seu representante de serviço da Red Hat.

Ao determinar o tamanho de seu sistema de arquivos, você deve considerar suas necessidades de recuperação. A execução do comando fsck.gfs2 em um sistema de arquivo muito grande pode levar muito tempo e consumir uma grande quantidade de memória. Além disso, no caso de uma falha no disco ou subsistema de disco, o tempo de recuperação é limitado pela velocidade de sua mídia de backup. Para informações sobre a quantidade de memória que o comando fsck.gfs2 requer, veja Determinar a memória necessária para executar o fsck.gfs2.

Enquanto um sistema de arquivo GFS2 pode ser usado fora do LVM, a Red Hat suporta apenas sistemas de arquivo GFS2 que são criados em um volume lógico LVM compartilhado.

Esta seção fornece recomendações sobre como formatar seu sistema de arquivos GFS2 para otimizar o desempenho.

Tamanho do sistema de arquivo: Mais pequeno é melhor

O GFS2 é baseado em uma arquitetura de 64 bits, que teoricamente pode acomodar um sistema de arquivos 8 EB. Entretanto, o tamanho máximo atualmente suportado de um sistema de arquivo GFS2 para hardware de 64 bits é de 100TB.

Observe que, embora os sistemas de arquivos grandes GFS2 sejam possíveis, isso não significa que eles sejam recomendados. A regra geral com GFS2 é que menor é melhor: é melhor ter sistemas de arquivo de 10 1TB do que um sistema de arquivo de 10TB.

Há várias razões pelas quais você deve manter seus sistemas de arquivos GFS2 pequenos:

Além disso, menos grupos de recursos para manter significam um melhor desempenho.

É claro, se você tornar seu sistema de arquivos GFS2 muito pequeno, você pode ficar sem espaço, e isso tem suas próprias conseqüências. Você deve considerar seus próprios casos de uso antes de decidir sobre um tamanho.

Tamanho do bloco: Blocos padrão (4K) são preferidos

O comando mkfs.gfs2 tenta estimar um tamanho de bloco ideal com base na topologia do dispositivo. Em geral, blocos 4K são o tamanho de bloco preferido porque 4K é o tamanho de página padrão (memória) para o Red Hat Enterprise Linux. Ao contrário de alguns outros sistemas de arquivo, o GFS2 faz a maioria de suas operações usando buffers de kernel 4K. Se seu tamanho de bloco for 4K, o kernel tem que fazer menos trabalho para manipular os buffers.

Recomenda-se usar o tamanho padrão do bloco, que deve render o mais alto desempenho. Você pode precisar usar um tamanho de bloco diferente somente se você precisar de um armazenamento eficiente de muitos arquivos muito pequenos.

Tamanho da revista: Padrão (128MB) Normalmente é o ideal

Ao executar o comando mkfs.gfs2 para criar um sistema de arquivos GFS2, você pode especificar o tamanho dos periódicos. Se você não especificar um tamanho, ele será padrão para 128MB, o que deve ser ideal para a maioria das aplicações.

Alguns administradores de sistema podem pensar que 128MB é excessivo e ser tentados a reduzir o tamanho do periódico para o mínimo de 8MB ou um 32MB mais conservador. Embora isso possa funcionar, pode ter um impacto severo no desempenho. Como muitos sistemas de arquivo de periódicos, toda vez que o GFS2 escreve metadados, os metadados são comprometidos com o periódico antes de ser colocado em funcionamento. Isto assegura que se o sistema falhar ou perder energia, você recuperará todos os metadados quando o periódico for reproduzido automaticamente no momento da montagem. Entretanto, não é necessária muita atividade do sistema de arquivos para preencher um diário de 8MB, e quando o diário está cheio, o desempenho diminui porque o GFS2 tem que esperar por escritos para o armazenamento.

Recomenda-se geralmente usar o tamanho padrão do diário de 128MB. Se seu sistema de arquivo for muito pequeno (por exemplo, 5GB), ter um diário de 128MB pode ser impraticável. Se você tiver um sistema de arquivo maior e puder arcar com o espaço, o uso de periódicos de 256MB pode melhorar o desempenho.

Tamanho e número de grupos de recursos

Quando um sistema de arquivo GFS2 é criado com o comando mkfs.gfs2, ele divide o armazenamento em fatias uniformes conhecidas como grupos de recursos. Ele tenta estimar um tamanho ideal de grupo de recursos (variando de 32MB a 2GB). Você pode substituir o padrão com a opção -r do comando mkfs.gfs2.

O tamanho ideal de seu grupo de recursos depende de como você utilizará o sistema de arquivo. Considere quão cheio ele estará e se será ou não severamente fragmentado.

Você deve experimentar com diferentes tamanhos de grupos de recursos para ver qual resulta em um ótimo desempenho. É uma melhor prática experimentar com um grupo de teste antes de implantar o GFS2 na produção total.

Se seu sistema de arquivo tiver muitos grupos de recursos, cada um deles muito pequeno, a alocação de blocos pode perder muito tempo procurando dezenas de milhares de grupos de recursos por um bloco livre. Quanto mais cheio seu sistema de arquivo, mais grupos de recursos serão pesquisados, e cada um deles requer um bloqueio de cluster. Isto leva a um desempenho lento.

Se, no entanto, seu sistema de arquivo tiver muito poucos grupos de recursos, cada um dos quais é muito grande, as alocações de blocos podem ter mais freqüência para o mesmo bloqueio de grupo de recursos, o que também impacta o desempenho. Por exemplo, se você tem um sistema de arquivo de 10GB que é dividido em cinco grupos de recursos de 2GB, os nós em seu grupo lutarão mais frequentemente por esses cinco grupos de recursos do que se o mesmo sistema de arquivo fosse dividido em 320 grupos de recursos de 32MB. O problema é exacerbado se seu sistema de arquivos estiver quase cheio porque cada alocação de blocos pode ter que procurar em vários grupos de recursos antes de encontrar um com um bloco livre. O GFS2 tenta mitigar este problema de duas maneiras:

O pior cenário é quando existe um diretório central no qual todos os nós criam arquivos porque todos os nós lutarão constantemente para bloquear o mesmo grupo de recursos.

Ao determinar o número de nós que seu sistema conterá, observe que existe um trade-off entre alta disponibilidade e desempenho. Com um número maior de nós, torna-se cada vez mais difícil fazer com que as cargas de trabalho aumentem. Por esse motivo, a Red Hat não suporta o uso do GFS2 para implantações de sistemas de arquivo de cluster maiores que 16 nós.

A implantação de um sistema de arquivo de cluster não é um substituto para a implantação de um único nó. A Red Hat recomenda que você permita um período de cerca de 8-12 semanas de testes em novas instalações a fim de testar o sistema e garantir que ele esteja trabalhando no nível de desempenho exigido. Durante este período, quaisquer questões de desempenho ou funcionais podem ser resolvidas e quaisquer dúvidas devem ser direcionadas à equipe de suporte da Red Hat.

A Red Hat recomenda que os clientes que considerem implantar clusters tenham suas configurações revisadas pelo suporte da Red Hat antes da implantação para evitar possíveis problemas de suporte posteriormente.

Você deve levar em conta as seguintes considerações de hardware ao implantar um sistema de arquivos GFS2.

Cada inode de arquivo e inode de diretório tem três carimbos de tempo associados a ele:

Se as atualizações do atime estiverem habilitadas como estão por padrão no GFS2 e em outros sistemas de arquivos Linux, então toda vez que um arquivo é lido, seu inode precisa ser atualizado.

Como poucas aplicações utilizam as informações fornecidas por atime, essas atualizações podem exigir uma quantidade significativa de tráfego de escrita desnecessária e tráfego de travamento de arquivos. Esse tráfego pode degradar o desempenho; portanto, pode ser preferível desligar ou reduzir a freqüência das atualizações de atime.

Os seguintes métodos para reduzir os efeitos da atualização do atime estão disponíveis:

Use o seguinte comando para montar um sistema de arquivo GFS2 com a opção de montagem em noatime Linux.

monte BlockDevice MountPoint -o noatime

Neste exemplo, o sistema de arquivos GFS2 reside em /dev/vg01/lvol0 e é montado no diretório /mygfs2 com atime atualizações desativadas.

# mount /dev/vg01/lvol0 /mygfs2 -o noatime

Como todos os sistemas de arquivo Linux, o GFS2 está sobre uma camada chamada sistema de arquivo virtual (VFS). O VFS fornece bons padrões para as configurações de cache para a maioria das cargas de trabalho e não deve precisar ser alterado na maioria dos casos. Se, no entanto, você tiver uma carga de trabalho que não esteja rodando eficientemente (por exemplo, o cache é muito grande ou muito pequeno), então você poderá melhorar o desempenho usando o comando sysctl(8) para ajustar os valores dos arquivos sysctl no diretório /proc/sys/vm. A documentação para estes arquivos pode ser encontrada na árvore de fontes do kernel Documentation/sysctl/vm.txt.

Por exemplo, os valores para dirty_background_ratio e vfs_cache_pressure podem ser ajustados, dependendo de sua situação. Para obter os valores atuais, use os seguintes comandos:

# sysctl -n vm.dirty_background_ratio
# sysctl -n vm.vfs_cache_pressure

Os seguintes comandos ajustam os valores:

# sysctl -w vm.dirty_background_ratio=20
# sysctl -w vm.vfs_cache_pressure=500

Você pode alterar permanentemente os valores destes parâmetros editando o arquivo /etc/sysctl.conf.

Para encontrar os valores ideais para seus casos de uso, pesquise as várias opções de VFS e experimente em um grupo de teste antes de implantar em produção plena.

O uso do Security Enhanced Linux (SELinux) com GFS2 incorre em uma pequena penalidade de desempenho. Para evitar esta sobrecarga, você pode optar por não utilizar o SELinux com GFS2 mesmo em um sistema com SELinux em modo de aplicação. Ao montar um sistema de arquivo GFS2, você pode garantir que o SELinux não tentará ler o elemento seclabel em cada objeto do sistema de arquivo usando uma das opções context, conforme descrito na página de manual mount(8); o SELinux assumirá que todo o conteúdo do sistema de arquivo está etiquetado com o elemento seclabel fornecido nas opções de montagem context. Isto também agilizará o processamento, pois evita outra leitura em disco do bloco de atributos estendido que poderia conter elementos seclabel.

Por exemplo, em um sistema com SELinux em modo de aplicação, você pode usar o seguinte comando mount para montar o sistema de arquivos GFS2 se o sistema de arquivos for conter conteúdo Apache. Esta etiqueta será aplicada a todo o sistema de arquivo; ela permanece na memória e não é gravada em disco.

# mount -t gfs2 -o context=system_u:object_r:httpd_sys_content_t:s0 /dev/mapper/xyz/mnt/gfs2

Se você não tiver certeza se o sistema de arquivo conterá conteúdo Apache, você pode usar os rótulos public_content_rw_t ou public_content_t, ou você pode definir um novo rótulo e definir uma política em torno dele.

Observe que em um cluster Pacemaker você deve sempre usar Pacemaker para gerenciar um sistema de arquivos GFS2. Você pode especificar as opções de montagem ao criar um recurso de sistema de arquivo GFS2.

Devido à complexidade adicional do subsistema de travamento GFS2 e sua natureza agrupada, a configuração do NFS sobre o GFS2 requer tomar muitas precauções e uma configuração cuidadosa. Esta seção descreve as advertências que você deve levar em conta ao configurar um serviço NFS sobre um sistema de arquivos GFS2.

Além das considerações de bloqueio, você deve levar em conta o seguinte ao configurar um serviço NFS sobre um sistema de arquivos GFS2.

Você pode usar arquivos Samba (SMB ou Windows) servindo a partir de um sistema de arquivos GFS2 com CTDB, o que permite configurações ativas/atuantes.

O acesso simultâneo aos dados no Samba share a partir de fora do Samba não é suportado. Atualmente não há suporte para os aluguéis do cluster GFS2, o que retarda o serviço de arquivos do Samba. Para maiores informações sobre políticas de suporte para Samba, veja Políticas de Suporte para Armazenamento Resiliente RHEL - ctdb Políticas Gerais e Políticas de Suporte para Armazenamento Resiliente RHEL - Exportação de conteúdo gfs2 através de outros protocolos no Portal do Cliente da Red Hat.

Ao utilizar um sistema de arquivo GFS2 com uma máquina virtual, é importante que suas configurações de armazenamento de VM em cada nó sejam configuradas corretamente para forçar o cache a ser desligado. Por exemplo, incluir estas configurações para cache e io no domínio libvirt deve permitir que o GFS2 se comporte como esperado.

<driver name='qemu' type='raw' cache='none' io='native'/>

Alternativamente, você pode configurar o atributo shareable dentro do elemento do dispositivo. Isto indica que o dispositivo deve ser compartilhado entre domínios (desde que o hypervisor e o SO suportem isto). Se shareable for usado, cache='no' deve ser usado para esse dispositivo.

Esta seção fornece um resumo das questões relacionadas à alocação de blocos nos sistemas de arquivos GFS2. Mesmo que aplicações que só escrevem dados normalmente não se importam como ou onde um bloco é alocado, algum conhecimento de como funciona a alocação de blocos pode ajudá-lo a otimizar o desempenho.

Você cria um sistema de arquivos GFS2 com o comando mkfs.gfs2. Um sistema de arquivo é criado em um volume LVM ativado.

mkfs.gfs2 -p lock_dlm -t ClusterName:FSName -j NumberJournals BlockDevice

mkfs -t gfs2 -p lock_dlm -t ClusterName:FSName -j NumberJournals BlockDevice

# mkfs.gfs2 -p lock_dlm -t alpha:mydata1 -j 8 /dev/vg01/lvol0
# mkfs.gfs2 -p lock_dlm -t alpha:mydata2 -j 8 /dev/vg01/lvol1

Antes que você possa montar um sistema de arquivo GFS2, o sistema de arquivo deve existir, o volume onde o sistema de arquivo existe deve ser ativado, e os sistemas de agrupamento e travamento de suporte devem ser iniciados. Após atender a esses requisitos, você pode montar o sistema de arquivo GFS2 como faria com qualquer sistema de arquivo Linux.

Para o bom funcionamento do sistema de arquivos GFS2, o pacote gfs2-utils deve ser instalado em todos os nós que montam um sistema de arquivos GFS2. O pacote gfs2-utils faz parte do canal de armazenamento resiliente.

Para manipular ACLs de arquivo, você deve montar o sistema de arquivo com a opção de montagem -o acl. Se um sistema de arquivo for montado sem a opção de montagem -o acl, os usuários podem visualizar as ACLs (com getfacl), mas não é permitido defini-las (com setfacl).

# mount /dev/vg01/lvol0 /mygfs2

montar BlockDevice MountPoint -o option

umount MountPoint

É importante fazer backups regulares de seu sistema de arquivos GFS2 em caso de emergência, independentemente do tamanho de seu sistema de arquivos. Muitos administradores de sistema se sentem seguros porque são protegidos por RAID, multicaminhos, espelhamento, instantâneos e outras formas de redundância, mas não existe tal coisa como seguro o suficiente.

Pode ser um problema criar um backup, já que o processo de backup de um nó ou conjunto de nós geralmente envolve a leitura de todo o sistema de arquivos em seqüência. Se isso for feito a partir de um único nó, esse nó reterá todas as informações no cache até que outros nós do cluster comecem a solicitar bloqueios. A execução deste tipo de programa de backup enquanto o cluster estiver em operação terá um impacto negativo no desempenho.

Soltar as caches uma vez que o backup esteja completo reduz o tempo exigido pelos outros nós para recuperar a propriedade de suas fechaduras/caches de cluster. Isto ainda não é ideal, no entanto, porque os outros nós terão parado de armazenar em cache os dados que estavam armazenando antes do início do processo de backup. Você pode soltar os caches usando o seguinte comando depois que o backup estiver completo:

echo -n 3 > /proc/sys/vm/drop_caches

É mais rápido se cada nó do cluster fizer backup de seus próprios arquivos para que a tarefa seja dividida entre os nós. Você pode conseguir isso com um script que usa o comando rsync em diretórios específicos de node-specific directories.

A Red Hat recomenda fazer um backup GFS2 criando um instantâneo de hardware na SAN, apresentando o instantâneo para outro sistema, e fazendo o backup lá em cima. O sistema de backup deve montar o snapshot com -o lockproto=lock_nolock, já que ele não estará em um cluster.

Você pode suspender a atividade de gravação em um sistema de arquivo usando o comando dmsetup suspend. Suspender a atividade de gravação permite que instantâneos de dispositivos baseados em hardware sejam usados para capturar o sistema de arquivo em um estado consistente. O comando dmsetup resume termina a suspensão.

O formato para o comando de suspensão de atividade em um sistema de arquivos GFS2 é o seguinte.

dmsetup suspender MountPoint

Este exemplo suspende a escrita no sistema de arquivo /mygfs2.

# dmsetup suspend /mygfs2

O formato para o comando para terminar a suspensão de atividade em um sistema de arquivo GFS2 é o seguinte.

currículo dmsetup MountPoint

Este exemplo acaba com a suspensão dos escritos ao sistema de arquivo /mygfs2.

# dmsetup resume /mygfs2

O comando gfs2_grow é usado para expandir um sistema de arquivo GFS2 após o dispositivo onde o sistema de arquivo reside ter sido expandido. A execução do comando gfs2_grow em um sistema de arquivo GFS2 existente preenche todo o espaço livre entre a extremidade atual do sistema de arquivo e o final do dispositivo com uma extensão do sistema de arquivo GFS2 recém-inicializada. Todos os nós do cluster podem então usar o espaço de armazenamento extra que foi adicionado.

O comando gfs2_grow deve ser executado em um sistema de arquivo montado. O seguinte procedimento aumenta o tamanho do sistema de arquivo GFS2 em um cluster que é montado no volume lógico shared_vg/shared_lv1 com um ponto de montagem de /mnt/gfs2.

O GFS2 requer um diário para cada nó em um cluster que precisa montar o sistema de arquivo. Se você adicionar nós adicionais ao cluster, você pode adicionar periódicos a um sistema de arquivos GFS2 com o comando gfs2_jadd. Você pode adicionar periódicos a um sistema de arquivos GFS2 dinamicamente em qualquer ponto sem expandir o volume lógico subjacente. O comando gfs2_jadd deve ser executado em um sistema de arquivo montado, mas ele precisa ser executado em apenas um nó no cluster. Todos os outros nós sentem que a expansão ocorreu.

Antes de adicionar periódicos a um sistema de arquivos GFS2, você pode descobrir quantos periódicos o sistema de arquivos GFS2 contém atualmente com o comando gfs2_edit -p jindex, como no exemplo a seguir:

# gfs2_edit -p jindex /dev/sasdrives/scratch|grep journal
   3/3 [fc7745eb] 4/25 (0x4/0x19): File    journal0
   4/4 [8b70757d] 5/32859 (0x5/0x805b): File    journal1
   5/5 [127924c7] 6/65701 (0x6/0x100a5): File    journal2

O formato para o comando básico para adicionar periódicos a um sistema de arquivos GFS2 é o seguinte.

gfs2_jadd -j Number MountPoint

Neste exemplo, uma revista é adicionada ao sistema de arquivos no diretório /mygfs2.

gfs2_jadd -j 1 /mygfs2

Para implementar cotas em disco, use as seguintes etapas:

Cada uma dessas etapas é discutida em detalhes nas seções seguintes.

# pcs resource create gfs2mount Filesystem options="quota=on" device=BLOCKDEVICE directory=MOUNTPOINT fstype=gfs2 clone

quotacheck -ug /home

# edquota username

Disk quotas for user testuser (uid 501):
Filesystem                blocks     soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440436        0        0

Disk quotas for user testuser (uid 501):
Filesystem                blocks     soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440436   500000   550000

# quota testuser

# edquota -g devel

Disk quotas for group devel (gid 505):
Filesystem                blocks    soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440400       0        0

$ quota -g devel

Se as cotas forem implementadas, elas precisam de alguma manutenção, principalmente na forma de vigiar para ver se as cotas são excedidas e certificar-se de que as cotas sejam precisas.

Se os usuários excederem repetidamente suas quotas ou atingirem de forma consistente seus limites de soft, um administrador de sistema tem algumas escolhas a fazer, dependendo do tipo de usuários que são e quanto espaço em disco impacta seu trabalho. O administrador pode ajudar o usuário a determinar como utilizar menos espaço em disco ou aumentar a cota de disco do usuário.

Você pode criar um relatório de uso do disco executando o utilitário repquota. Por exemplo, o comando repquota /home produz esta saída:

* Report for user quotas on device /dev/mapper/VolGroup00-LogVol02
Block grace time: 7days; Inode grace time: 7days
			Block limits			File limits
User		used	soft	hard	grace	used	soft	hard	grace
----------------------------------------------------------------------
root      --      36       0       0              4     0     0
kristin   --     540       0       0            125     0     0
testuser  --  440400  500000  550000          37418     0     0

Para visualizar o relatório de uso do disco para todos os sistemas de arquivos habilitados para quotas (opção -a), use o comando:

# repquota -a

O -- exibido após cada usuário é uma forma rápida de determinar se os limites do bloco foram excedidos. Se o limite do bloco for excedido, um aparece no lugar do primeiro - na saída. O segundo - indica o limite inode, mas os sistemas de arquivo GFS2 não suportam limites inode para que o caractere permaneça como -. Os sistemas de arquivo GFS2 não suportam um período de carência, de modo que a coluna grace permanecerá em branco.

Note que o comando repquota não é suportado sobre o NFS, independentemente do sistema de arquivo subjacente.

Se você ativar cotas em seu sistema de arquivos após um período de tempo em que você tenha sido executado com as cotas desativadas, você deve executar o comando quotacheck para criar, verificar e reparar arquivos de cotas. Além disso, você pode querer executar o comando quotacheck se achar que seus arquivos de cotas podem não ser precisos, como pode ocorrer quando um sistema de arquivos não é desmontado de forma limpa após uma falha do sistema.

Para mais informações sobre o comando quotacheck, consulte a página de manual quotacheck.

O GFS2 armazena em disco todas as informações de cota em seu próprio arquivo interno. Um nó GFS2 não atualiza este arquivo de cota para cada sistema de arquivo escrito; pelo contrário, por padrão, ele atualiza o arquivo de cota uma vez a cada 60 segundos. Isto é necessário para evitar contendas entre os nós que escrevem no arquivo de cota, o que causaria um retardamento no desempenho.

Medida que um usuário ou grupo se aproxima de seu limite de cota, o GFS2 reduz dinamicamente o tempo entre suas atualizações de arquivos de cota para evitar que o limite seja excedido. O período de tempo normal entre as sincronizações de cota é um parâmetro sintonizável, quota_quantum. Você pode mudar isto de seu valor padrão de 60 segundos usando a opção de montagem quota_quantum=, como descrito na tabela "GFS2-Specific Mount Options" em Mounting a GFS2 file system que especifica as opções de montagem.

O parâmetro quota_quantum deve ser definido em cada nó e cada vez que o sistema de arquivo é montado. As mudanças no parâmetro quota_quantum não são persistentes em montagens não montadas. Você pode atualizar o valor quota_quantum com o parâmetro mount -o remount.

Você pode usar o comando quotasync para sincronizar as informações de cota de um nó para o arquivo de cota em disco entre as atualizações automáticas realizadas pelo GFS2. Utilização Synchronizing Quota Information

# 'quotasync [-ug -a|mountpoint..a`].

Você pode ajustar o tempo entre as sincronizações especificando uma opção de montagem em quota-quantum.

# mount -o quota_quantum=secs,remount BlockDevice MountPoint

O exemplo a seguir sincroniza todas as cotas sujas em cache do nó em que é executado para o arquivo de cotas em disco para o sistema de arquivo /mnt/mygfs2.

# quotasync -ug /mnt/mygfs2

Este exemplo a seguir altera o período de tempo padrão entre atualizações regulares de arquivos de cota para uma hora (3600 segundos) para o sistema de arquivo /mnt/mygfs2 ao recontar esse sistema de arquivo no volume lógico /dev/volgroup/logical_volume.

# mount -o quota_quantum=3600,remount /dev/volgroup/logical_volume /mnt/mygfs2

A execução do comando fsck.gfs2 pode requerer memória do sistema acima e além da memória utilizada para o sistema operacional e o kernel. Sistemas de arquivos maiores, em particular, podem requerer memória adicional para executar este comando.

A tabela a seguir mostra valores aproximados de memória que podem ser necessários para executar sistemas de arquivo fsck.gfs2 em sistemas de arquivo GFS2 que são 1TB, 10TB e 100TB de tamanho com um bloco de 4K.

Observe que um bloco de tamanho menor para o sistema de arquivo exigiria uma quantidade maior de memória. Por exemplo, sistemas de arquivo GFS2 com um tamanho de bloco de 1K exigiriam quatro vezes a quantidade de memória indicada nesta tabela.

O seguinte mostra o formato do comando fsck.gfs2 para reparar um sistema de arquivos GFS2.

fsck.gfs2 -y BlockDevice

Neste exemplo, o sistema de arquivo GFS2 residente no dispositivo de bloco /dev/testvg/testlv é reparado. Todas as consultas para reparo são automaticamente respondidas com yes.

# fsck.gfs2 -y /dev/testvg/testlv
Initializing fsck
Validating Resource Group index.
Level 1 RG check.
(level 1 passed)
Clearing journals (this may take a while)...
Journals cleared.
Starting pass1
Pass1 complete
Starting pass1b
Pass1b complete
Starting pass1c
Pass1c complete
Starting pass2
Pass2 complete
Starting pass3
Pass3 complete
Starting pass4
Pass4 complete
Starting pass5
Pass5 complete
Writing changes to disk
fsck.gfs2 complete

Embora não exista uma ferramenta de desfragmentação para o GFS2 no Red Hat Enterprise Linux, você pode desfragmentar arquivos individuais identificando-os com a ferramenta filefrag, copiando-os para arquivos temporários e renomeando os arquivos temporários para substituir os originais.

A fim de obter o melhor desempenho de um sistema de arquivos GFS2, é importante entender algumas das teorias básicas de seu funcionamento. Um sistema de arquivo de nó único é implementado junto com um cache, cujo objetivo é eliminar a latência dos acessos ao disco quando se utilizam dados freqüentemente solicitados. No Linux, o cache de páginas (e historicamente o cache de buffer) fornece esta função de cache.

Com o GFS2, cada nó tem seu próprio cache de página que pode conter alguma porção dos dados em disco. O GFS2 usa um mecanismo de travamento chamado glocks (pronunciado gee-locks) para manter a integridade do cache entre os nós. O subsistema glock fornece uma função de gerenciamento de cache que é implementada usando o distributed lock manager (DLM) como a camada de comunicação subjacente.

Os glocks fornecem proteção para o cache por inode, de modo que há um cadeado por inode que é usado para controlar a camada de cache. Se essa glock for concedida em modo compartilhado (modo de bloqueio DLM: PR), então os dados sob essa glock podem ser armazenados em cache em um ou mais nós ao mesmo tempo, de modo que todos os nós possam ter acesso local aos dados.

Se a glock for concedida em modo exclusivo (modo de bloqueio DLM: EX), então somente um único nó pode armazenar os dados sob aquela glock. Este modo é usado por todas as operações que modificam os dados (como a chamada do sistema write ).

Se outro nó solicitar uma glock que não possa ser concedida imediatamente, então o DLM envia uma mensagem ao nó ou nós que atualmente seguram as glocks bloqueando o novo pedido para pedir-lhes que soltem suas fechaduras. Deixar cair os glocks pode ser (pelos padrões da maioria das operações do sistema de arquivos) um processo longo. Deixar cair uma glock compartilhada requer apenas que o cache seja invalidado, o que é relativamente rápido e proporcional à quantidade de dados em cache.

Para soltar uma glock exclusiva é necessário um log flush, e escrever de volta quaisquer dados alterados em disco, seguido da invalidação de acordo com a glock compartilhada.

A diferença entre um sistema de arquivo de nó único e o GFS2, então, é que um sistema de arquivo de nó único tem um único cache e o GFS2 tem um cache separado em cada nó. Em ambos os casos, a latência para acessar dados em cache é de uma ordem de magnitude semelhante, mas a latência para acessar dados não em cache é muito maior no GFS2 se outro nó tiver previamente armazenado em cache esses mesmos dados.

Operações como read (tamponada), stat, e readdir requerem apenas uma glock compartilhada. Operações como write (tamponada), mkdir, rmdir e unlink requerem uma glock exclusiva. Operações de leitura/escrita de E/S direta requerem uma glock adiada se nenhuma alocação estiver ocorrendo, ou uma glock exclusiva se a escrita exigir uma alocação (ou seja, extensão do arquivo, ou preenchimento de buracos).

Há duas considerações principais de desempenho que decorrem disso. Em primeiro lugar, as operações somente de leitura paralelizam extremamente bem em um cluster, uma vez que podem funcionar independentemente em cada nó. Segundo, as operações que requerem uma glock exclusiva podem reduzir o desempenho, se houver vários nós disputando o acesso ao(s) mesmo(s) inodo(s). A consideração do conjunto de trabalho em cada nó é, portanto, um fator importante no desempenho do sistema de arquivos GFS2, como, por exemplo, quando se realiza um backup do sistema de arquivos, como descrito em Backing up de um sistema de arquivos GFS2.

Uma outra conseqüência disto é que recomendamos o uso da opção de montagem noatime ou nodiratime com GFS2 sempre que possível, com a preferência por noatime onde a aplicação permite isto. Isto evita que as leituras necessitem de fechaduras exclusivas para atualizar o timestamp atime.

Para usuários preocupados com o conjunto de trabalho ou com a eficiência do cache, o GFS2 fornece ferramentas que permitem monitorar o desempenho de um sistema de arquivos GFS2: Co-piloto de desempenho e pontos de rastreamento GFS2.

Ao utilizar o travamento Posix, você deve levar em conta o seguinte:

Geralmente é possível alterar a forma como uma aplicação problemática armazena seus dados a fim de obter uma vantagem considerável de desempenho.

Um exemplo típico de uma aplicação problemática é um servidor de e-mail. Estes são freqüentemente dispostos com um diretório spool contendo arquivos para cada usuário (mbox), ou com um diretório para cada usuário contendo um arquivo para cada mensagem (maildir). Quando os pedidos chegam por IMAP, a disposição ideal é dar a cada usuário uma afinidade com um nó em particular. Dessa forma, suas solicitações para visualizar e excluir mensagens de e-mail tenderão a ser servidas a partir do cache daquele nó. Obviamente, se esse nó falhar, então a sessão poderá ser reiniciada em um nó diferente.

Quando o correio chega por meio de SMTP, então novamente os nós individuais podem ser configurados de forma a passar um determinado correio do usuário para um determinado nó por padrão. Se o nó padrão não estiver ativo, então a mensagem pode ser salva diretamente no spool de correio do usuário pelo nó de recebimento. Mais uma vez, este projeto visa manter conjuntos particulares de arquivos em cache em apenas um nó no caso normal, mas para permitir acesso direto no caso de falha do nó.

Esta configuração permite o melhor uso do cache de páginas do GFS2 e também torna as falhas transparentes para a aplicação, seja imap ou smtp.

O Backup é muitas vezes outra área complicada. Novamente, se for possível, é muito preferível fazer o backup do conjunto de trabalho de cada nó diretamente do nó que está armazenando aquele conjunto particular de nós. Se você tem um script de backup que roda em um ponto regular no tempo, e isso parece coincidir com um pico no tempo de resposta de uma aplicação rodando no GFS2, então há uma boa chance de que o cluster possa não estar fazendo o uso mais eficiente do cache de páginas.

Obviamente, se você estiver na posição de poder interromper a aplicação para realizar um backup, então isto não será um problema. Por outro lado, se um backup for executado a partir de apenas um nó, então, depois de ter completado uma grande parte do sistema de arquivos será colocado em cache naquele nó, com uma penalidade de desempenho para acessos subseqüentes a partir de outros nós. Isto pode ser mitigado, até certo ponto, deixando cair o cache de páginas VFS no nó de backup depois que o backup for completado com o seguinte comando:

echo -n 3 >/proc/sys/vm/drop_caches

No entanto, esta não é uma solução tão boa quanto o cuidado de garantir que o conjunto de trabalho em cada nó seja compartilhado, em sua maioria somente de leitura, ou acessado em grande parte a partir de um único nó.

Se seu desempenho de cluster estiver sofrendo devido ao uso ineficiente do cache GFS2, você poderá ver grandes e crescentes tempos de espera de E/S. Você pode fazer uso das informações de lock dump do GFS2 para determinar a causa do problema.

Esta seção fornece uma visão geral do lixão de eclusas GFS2.

As informações sobre o lixão GFS2 podem ser coletadas no arquivo debugfs que pode ser encontrado no seguinte caminho, assumindo que debugfs esteja montado em /sys/kernel/debug/:

/sys/kernel/debug/gfs2/fsname/glocks

O conteúdo do arquivo é uma série de linhas. Cada linha começando com G: representa uma glock, e as seguintes linhas, recuadas por um único espaço, representam um item de informação relativo à glock imediatamente antes delas no arquivo.

A melhor maneira de usar o arquivo debugfs é usar o comando cat para obter uma cópia do conteúdo completo do arquivo (pode levar muito tempo se você tiver uma grande quantidade de RAM e muitos inodes em cache) enquanto a aplicação está enfrentando problemas, e então olhar os dados resultantes em uma data posterior.

As linhas no arquivo debugfs que começam com H: (titulares) representam pedidos de fechaduras concedidas ou à espera de serem concedidas. O campo das bandeiras na linha f: mostra qual: A bandeira "W" se refere a um pedido de espera, a bandeira "H" se refere a um pedido deferido. Os glocks que têm um grande número de pedidos de espera são provavelmente aqueles que estão passando por uma disputa particular.

Tabela 6.1, “Bandeiras Glock” mostra os significados das diferentes bandeiras porta-bandeiras e Tabela 6.2, “Bandeiras porta-bandeiras Glock” mostra os significados das diferentes bandeiras porta-bandeiras.

Tendo identificado uma glock que está causando um problema, o próximo passo é descobrir com qual inode ela se relaciona. O número da glóculo (n: na linha G:) indica isto. É do formulário type/number e se type é 2, então a glock é um inode glock e o number é um inode number. Para rastrear o inode, você pode então executar find -inum number onde number é o número do inode convertido do formato hexadecimal no arquivo de glocks em decimal.

Tabela 6.3, “Tipos de Glock” mostra os significados dos diferentes tipos de glock.

Se a glock que foi identificada era de um tipo diferente, então é mais provável que seja do tipo 3: (grupo de recursos). Se você vir um número significativo de processos esperando por outros tipos de glock sob cargas normais, informe isso ao suporte da Red Hat.

Se você vir uma série de pedidos em fila de espera em um bloqueio de grupo de recursos, pode haver uma série de razões para isso. Uma delas é que há um grande número de nós em comparação com o número de grupos de recursos no sistema de arquivos. Outra é que o sistema de arquivos pode estar muito próximo de estar cheio (exigindo, em média, buscas mais longas por blocos livres). A situação em ambos os casos pode ser melhorada adicionando mais armazenamento e usando o comando gfs2_grow para expandir o sistema de arquivo.

Normalmente, o GFS2 escreve apenas metadados para sua revista. O conteúdo do arquivo é posteriormente escrito em disco pela sincronização periódica do kernel que descarrega os buffers do sistema de arquivos. Uma chamada ao arquivo fsync() faz com que os dados do arquivo sejam imediatamente gravados em disco. A chamada retorna quando o disco informa que todos os dados estão gravados com segurança.

O diário de dados pode resultar em uma redução do tempo fsync() para arquivos muito pequenos porque os dados do arquivo são escritos no diário, além dos metadados. Esta vantagem se reduz rapidamente à medida que o tamanho do arquivo aumenta. A escrita em arquivos médios e grandes será muito mais lenta com o diário de dados ligado.

As aplicações que dependem do fsync() para sincronizar dados de arquivos podem ver um melhor desempenho ao usar o data journaling. O diário de dados pode ser ativado automaticamente para qualquer arquivo GFS2 criado em um diretório sinalizado (e todos os seus subdiretórios). Os arquivos existentes com comprimento zero também podem ter o diário de dados ligado ou desligado.

A ativação do diário de dados em um diretório define o diretório como "herdar jdata", o que indica que todos os arquivos e diretórios criados subseqüentemente nesse diretório são diários. Você pode ativar e desativar o diário de dados em um arquivo com o comando chattr.

Os comandos a seguir permitem o diário de dados no arquivo /mnt/gfs2/gfs2_dir/newfile e, em seguida, verificar se a bandeira foi colocada corretamente.

# chattr +j /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
---------j--- /mnt/gfs2/gfs2_dir/newfile

Os seguintes comandos desativam o diário de dados no arquivo /mnt/gfs2/gfs2_dir/newfile e depois verificam se a bandeira foi colocada corretamente.

# chattr -j /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
------------- /mnt/gfs2/gfs2_dir/newfile

Você também pode usar o comando chattr para colocar a bandeira j em um diretório. Quando você configura esta bandeira para um diretório, todos os arquivos e diretórios criados subseqüentemente nesse diretório são registrados no diário. O conjunto de comandos a seguir coloca a bandeira j no diretório gfs2_dir e, em seguida, verifica se a bandeira foi colocada corretamente. Depois disso, os comandos criam um novo arquivo chamado newfile no diretório /mnt/gfs2/gfs2_dir e então verificam se o sinalizador j foi definido para o arquivo. Como a bandeira j está configurada para o diretório, então newfile também deve ter o journaling habilitado.

# chattr -j /mnt/gfs2/gfs2_dir
# lsattr /mnt/gfs2
---------j--- /mnt/gfs2/gfs2_dir
# touch /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
---------j--- /mnt/gfs2/gfs2_dir/newfile

A função GFS2 withdraw é uma característica de integridade de dados do sistema de arquivos GFS2 que evita possíveis danos ao sistema de arquivos devido a hardware ou software do kernel defeituoso. Se o módulo de kernel GFS2 detectar uma inconsistência ao usar um sistema de arquivo GFS2 em um determinado nó de cluster, ele se retira do sistema de arquivo, deixando-o indisponível para aquele nó até que seja desmontado e remontado (ou a máquina que detecta o problema seja reinicializada). Todos os outros sistemas de arquivo GFS2 montados permanecem totalmente funcionais naquele nó. (A função de retirada do GFS2 é menos severa do que um pânico no núcleo, o que faz com que o nó seja cercado)

As principais categorias de inconsistência que podem causar uma retirada do GFS2 são as seguintes:

Um exemplo de uma inconsistência que causaria uma retirada do GFS2 é uma contagem de blocos incorreta para o inode de um arquivo. Quando o GFS2 apaga um arquivo, ele remove sistematicamente todos os blocos de dados e metadados referenciados por aquele arquivo. Quando feito, ele verifica a contagem de blocos do inode. Se a contagem de blocos não for 1 (significando que tudo o que resta é o próprio inode do disco), isso indica uma inconsistência do sistema de arquivo, uma vez que a contagem de blocos do inode não correspondeu aos blocos reais usados para o arquivo.

Em muitos casos, o problema pode ter sido causado por hardware defeituoso (memória defeituosa, placa-mãe, HBA, drives de disco, cabos, e assim por diante). Pode também ter sido causado por um bug no kernel (outro módulo do kernel sobregravando acidentalmente a memória do GFS2), ou por danos reais ao sistema de arquivos (causados por um bug GFS2).

Na maioria dos casos, a melhor maneira de recuperar de um sistema de arquivo GFS2 retirado é reinicializar ou cercar o nó. O sistema de arquivo GFS2 retirado lhe dará a oportunidade de realocar os serviços para outro nó no cluster. Após a realocação dos serviços, você pode reinicializar o nó ou forçar uma cerca com este comando.

# pcs stonith fence node

O problema de consistência que causou a retirada pode impossibilitar a interrupção do serviço do sistema de arquivos, pois pode causar a suspensão do sistema.

Se o problema persistir após uma montagem posterior, você deve parar o serviço de sistema de arquivo para desmontar o sistema de arquivo de todos os nós no cluster, então execute uma verificação do sistema de arquivo com o comando fsck.gfs2 antes de reiniciar o serviço com o seguinte procedimento.

Você pode anular a função de retirada do GFS2 montando o sistema de arquivo com a opção -o errors=panic especificada no serviço de sistema de arquivo.

# pcs resource update mydata_fs “options=noatime,errors=panic”

Quando esta opção é especificada, quaisquer erros que normalmente causariam a retirada do sistema forçam um pânico no núcleo. Isto interrompe as comunicações do nó, o que faz com que o nó seja cercado. Isto é especialmente útil para clusters que são deixados sem vigilância por longos períodos de tempo sem monitoramento ou intervenção.

Internamente, a função de retirada do GFS2 funciona desligando o protocolo de travamento para garantir que todas as demais operações do sistema de arquivos resultem em erros de E/S. Como resultado, quando a retirada ocorre, é normal ver uma série de erros de E/S do dispositivo de mapeamento relatados nos logs do sistema.

Se seu sistema de arquivos GFS2 estiver pendurado e não retornar comandos executados contra ele, mas reiniciar um nó específico retorna o sistema ao normal, isto pode ser indicativo de um problema de travamento ou bug. Caso isso ocorra, colete os dados GFS2 durante uma dessas ocorrências e abra um ticket de suporte com o Red Hat Support, conforme descrito em Coleta de dados GFS2 para solução de problemas.

Se seu sistema de arquivos GFS2 estiver pendurado e não retornar comandos executados contra ele, exigindo que você reinicie todos os nós do cluster antes de usá-lo, verifique as seguintes questões.

Se você adicionar um novo nó a um cluster e descobrir que não pode montar seu sistema de arquivos GFS2 naquele nó, você poderá ter menos periódicos no sistema de arquivos GFS2 do que nós que tentam acessar o sistema de arquivos GFS2. Você deve ter um periódico por host GFS2 no qual pretende montar o sistema de arquivo (com exceção dos sistemas de arquivo GFS2 montados com o conjunto de opções de montagem spectator, uma vez que estes não requerem um periódico). Você pode adicionar periódicos a um sistema de arquivo GFS2 com o comando gfs2_jadd. Adicionando periódicos a um sistema de arquivo GFS2.

If you have an empty GFS2 file system, the df command will show that there is space being taken up. This is because GFS2 file system journals consume space (number of journals * journal size) on disk. If you created a GFS2 file system with a large number of journals or specified a large journal size then you will be see (number of journals * journal size) as already in use when you execute the df command. Even if you did not specify a large number of journals or large journals, small GFS2 file systems (in the 1GB or less range) will show a large amount of space as being in use with the default GFS2 journal size.

Se seu sistema de arquivos GFS2 estiver pendurado e não retornar comandos executados contra ele e você descobrir que precisa abrir um ticket com o Suporte da Red Hat, você deve primeiro reunir os seguintes dados:

Uma vez coletados esses dados, você pode abrir um ticket com o Suporte da Red Hat e fornecer os dados coletados.

Existem atualmente três tipos de tracepoints GFS2: glock (pronuncia-se "gee-lock") tracepoints, bmap tracepoints e log tracepoints. Estes podem ser usados para monitorar um sistema de arquivo GFS2 em execução e dar informações adicionais àquelas que podem ser obtidas com as opções de depuração suportadas em versões anteriores do Red Hat Enterprise Linux. Os tracepoints são particularmente úteis quando um problema, tal como um pendrive ou um problema de desempenho, é reproduzível e, portanto, a saída de tracepoints pode ser obtida durante a operação problemática. No GFS2, os glocks são o principal mecanismo de controle do cache e são a chave para entender o desempenho do núcleo do GFS2. O bmap (mapa de blocos) tracepoints pode ser usado para monitorar alocações de blocos e mapeamento de blocos (busca de blocos já alocados na árvore de metadados em disco) à medida que eles acontecem e verificar quaisquer questões relacionadas à localidade de acesso. Os log tracepoints acompanham os dados que estão sendo escritos e liberados da revista e podem fornecer informações úteis sobre essa parte do GFS2.

Os traços são projetados para serem o mais genéricos possível. Isto deve significar que não será necessário alterar a API durante o curso do Red Hat Enterprise Linux 8. Por outro lado, os usuários desta interface devem estar cientes de que esta é uma interface de depuração e não faz parte do conjunto normal da API do Red Hat Enterprise Linux 8, e como tal a Red Hat não dá garantias de que não ocorram mudanças na interface de tracepoints GFS2.

Os tracepoints são uma característica genérica do Red Hat Enterprise Linux e seu escopo vai muito além do GFS2. Em particular, eles são usados para implementar a infra-estrutura blktrace e o blktrace tracepoints podem ser usados em combinação com os do GFS2 para obter uma imagem mais completa do desempenho do sistema. Devido ao nível em que os tracepoints operam, eles podem produzir grandes volumes de dados em um período de tempo muito curto. Eles são projetados para colocar uma carga mínima no sistema quando são habilitados, mas é inevitável que eles tenham algum efeito. A filtragem de eventos por diversos meios pode ajudar a reduzir o volume de dados e ajudar a concentrar-se na obtenção apenas das informações úteis para a compreensão de qualquer situação particular.

Os tracepoints podem ser encontrados sob o diretório /sys/kernel/debug/tracing/ assumindo que debugfs esteja montado no local padrão no diretório /sys/kernel/debug. O subdiretório events contém todos os eventos de rastreamento que podem ser especificados e, desde que o módulo gfs2 seja carregado, haverá um subdiretório gfs2 contendo outros subdiretórios, um para cada evento GFS2. O conteúdo do diretório /sys/kernel/debug/tracing/events/gfs2 deve se parecer mais ou menos com o seguinte:

[root@chywoon gfs2]# ls
enable            gfs2_bmap       gfs2_glock_queue         gfs2_log_flush
filter            gfs2_demote_rq  gfs2_glock_state_change  gfs2_pin
gfs2_block_alloc  gfs2_glock_put  gfs2_log_blocks          gfs2_promote

Para habilitar todos os tracepoints GFS2, digite o seguinte comando:

[root@chywoon gfs2]# echo -n 1 >/sys/kernel/debug/tracing/events/gfs2/enable

Para permitir um traço específico, há um arquivo enable em cada um dos subdiretórios de eventos individuais. O mesmo se aplica ao arquivo filter que pode ser usado para definir um filtro de eventos para cada evento ou conjunto de eventos. O significado dos eventos individuais é explicado com mais detalhes abaixo.

A saída dos tracepoints está disponível em ASCII ou em formato binário. Este apêndice não cobre atualmente a interface binária. A interface ASCII está disponível de duas maneiras. Para listar o conteúdo atual do buffer de anéis, você pode digitar o seguinte comando:

[root@chywoon gfs2]# cat /sys/kernel/debug/tracing/trace

Esta interface é útil nos casos em que você está usando um processo de longa duração por um determinado período de tempo e, após algum evento, quer olhar para trás para as últimas informações capturadas no buffer. Uma interface alternativa, /sys/kernel/debug/tracing/trace_pipe, pode ser usada quando toda a saída for necessária. Os eventos são lidos a partir deste arquivo à medida que ocorrem; não há informações históricas disponíveis através desta interface. O formato da saída é o mesmo de ambas as interfaces e é descrito para cada um dos eventos GFS2 nas últimas seções deste apêndice.

Um utilitário chamado trace-cmd está disponível para a leitura de dados de tracepoint. Para maiores informações sobre este utilitário, veja o link em Seção 8.10, “Referências”. O utilitário trace-cmd pode ser usado de forma similar ao utilitário strace, por exemplo, para executar um comando durante a coleta de dados de rastreamento de várias fontes.

Para entender o GFS2, o conceito mais importante a entender, e o que o diferencia de outros sistemas de arquivo, é o conceito de glocks. Em termos de código fonte, um glock é uma estrutura de dados que reúne o DLM e o caching em uma única máquina de estado. Cada glock tem uma relação 1:1 com uma única fechadura DLM, e fornece cache para esse estado de fechamento, de modo que as operações repetitivas realizadas a partir de um único nó do sistema de arquivo não tenham que chamar repetidamente o DLM, e assim ajudam a evitar tráfego desnecessário na rede. Há duas grandes categorias de glocks, aqueles que armazenam metadados e aqueles que não o fazem. Os glocks de inode e o grupo de recursos fazem ambos os metadados de cache, outros tipos de glocks não fazem o cache de metadados. O inode glock também está envolvido no cache de dados além dos metadados e tem a lógica mais complexa de todos os glocks.

As glocks permanecem na memória até que sejam desbloqueadas (a pedido de outro nó ou a pedido do VM) e não haja usuários locais. Nesse momento, elas são removidas da mesa de hash da glock e liberadas. Quando uma glock é criada, o bloqueio DLM não é associado à glock imediatamente. A trava DLM torna-se associada à glock na primeira solicitação à DLM, e se esta solicitação for bem sucedida, então a bandeira "I" (inicial) será colocada na glock. Tabela 8.4, “Bandeiras Glock” mostra os significados das diferentes bandeiras da glock. Uma vez que a DLM tenha sido associada à glock, a trava DLM permanecerá sempre pelo menos no modo NL (Null) até que a glock seja liberada. Uma despromoção da trava DLM de NL para desbloqueada é sempre a última operação na vida de uma bata.

Cada glock pode ter um número de "suportes" associados a ela, cada um dos quais representa um pedido de bloqueio das camadas superiores. Chamadas de sistema relativas aos suportes de fila e dequeue GFS2 da glock para proteger a seção crítica do código.

A máquina de estado de glock é baseada em uma fila de trabalho. Por razões de desempenho, seria preferível a tasklets; entretanto, na implementação atual, precisamos apresentar E/S daquele contexto que proíbe seu uso.

Tabela 8.2, “Modos e tipos de dados da Glock” mostra que estado pode estar em cache sob cada um dos modos de glock e se esse estado em cache pode estar sujo. Isto se aplica tanto aos bloqueios inode quanto aos do grupo de recursos, embora não haja nenhum componente de dados para os bloqueios do grupo de recursos, apenas metadados.

A interface debugfs da glock permite a visualização do estado interno das glocks e dos suportes e também inclui alguns detalhes resumidos dos objetos que estão sendo trancados em alguns casos. Cada linha do arquivo ou começa com G: sem recuo (que se refere à própria glock) ou começa com uma letra diferente, recuada com um único espaço, e refere-se às estruturas associadas à glock imediatamente acima dela no arquivo (H: é um suporte, I: um inode, e R: um grupo de recursos) . Aqui está um exemplo de como poderia ser o conteúdo deste arquivo:

G:  s:SH n:5/75320 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:EX n:3/258028 f:yI t:EX d:EX/0 a:3 r:4
 H: s:EX f:tH e:0 p:4466 [postmark] gfs2_inplace_reserve_i+0x177/0x780 [gfs2]
 R: n:258028 f:05 b:22256/22256 i:16800
G:  s:EX n:2/219916 f:yfI t:EX d:EX/0 a:0 r:3
 I: n:75661/219916 t:8 f:0x10 d:0x00000000 s:7522/7522
G:  s:SH n:5/127205 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:EX n:2/50382 f:yfI t:EX d:EX/0 a:0 r:2
G:  s:SH n:5/302519 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/313874 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/271916 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/312732 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]

O exemplo acima é uma série de trechos (de um arquivo de aproximadamente 18MB) gerados pelo comando cat /sys/kernel/debug/gfs2/unity:myfs/glocks >my.lock durante uma execução do benchmark do carimbo do correio em um único nó do sistema de arquivos GFS2. Os glocks da figura foram selecionados a fim de mostrar algumas das características mais interessantes das lixeiras de glock.

Os estados de glock são EX (exclusivo), DF (diferido), SH (compartilhado) ou UN (desbloqueado). Estes estados correspondem diretamente aos modos de bloqueio DLM, exceto ONU, que pode representar ou o estado de bloqueio DLM nulo, ou que o GFS2 não possui um bloqueio DLM (dependendo da bandeira I, conforme explicado acima). O s: campo da glock indica o estado atual da fechadura e o mesmo campo no suporte indica o modo solicitado. Se a fechadura for concedida, o detentor terá o bit H ajustado em suas bandeiras (f: campo). Caso contrário, ele terá o bit W de espera ajustado.

O n: campo (número) indica o número associado a cada item. Para glocks, este é o número do tipo seguido pelo número da glock, de modo que no exemplo acima, a primeira glock é n:5/75320; o que indica uma glock iopen que se relaciona ao inode 75320. No caso das glocos inode e iopen, o número da glock é sempre idêntico ao número do bloco de disco do inode.

A listagem completa de todas as bandeiras, tanto para o titular como para a glande, encontra-se em Tabela 8.4, “Bandeiras Glock” e Tabela 8.5, “Bandeiras porta-bandeiras Glock”. O conteúdo dos blocos de valores de bloqueio não está atualmente disponível através da interface da glock debugfs.

Tabela 8.3, “Tipos de Glock” mostra os significados dos diferentes tipos de glock.

Uma das bandeiras glock mais importantes é a bandeira l (bloqueada). Esta é a bit lock que é usada para arbitrar o acesso ao estado de glock quando uma mudança de estado deve ser realizada. Ela é definida quando a máquina de estado está prestes a enviar um pedido de bloqueio remoto através do DLM, e só é liberada quando a operação completa tiver sido realizada. Às vezes isto pode significar que mais de uma solicitação de bloqueio terá sido enviada, com várias invalidações ocorrendo entre as vezes.

Tabela 8.4, “Bandeiras Glock” mostra os significados das diferentes bandeiras de glock.

Quando uma chamada remota é recebida de um nó que deseja obter uma fechadura em um modo que entre em conflito com o que está sendo mantido no nó local, então uma ou outra das duas bandeiras D (demote) ou d (demote pending) é definida. A fim de evitar condições de fome quando há contendas em uma determinada eclusa, a cada eclusa é atribuído um tempo mínimo de retenção. Um nó que ainda não teve a eclusa pelo tempo mínimo de retenção é autorizado a reter essa eclusa até que o intervalo de tempo tenha expirado.

Se o intervalo de tempo tiver expirado, então a bandeira D (demotada) será colocada e o estado requerido será registrado. Nesse caso, na próxima vez que não houver fechaduras concedidas na fila de titulares, a fechadura será rebaixada. Se o intervalo de tempo não tiver expirado, então a bandeira d (demote pendente) será colocada no lugar dela. Isto também programa a máquina de estado para liberar a d (demote pendente) e definir a D (demote) quando o tempo mínimo de espera tiver expirado.

A bandeira I (inicial) é colocada quando a glock tiver sido atribuída a uma fechadura DLM. Isto acontece quando a glock é usada pela primeira vez e a bandeira I permanecerá então definida até que a glock seja finalmente liberada (a qual a trava DLM é desbloqueada).

Tabela 8.5, “Bandeiras porta-bandeiras Glock” mostra os significados das diferentes bandeiras porta-glock.

As bandeiras mais importantes são H (suporte) e W (espera), como mencionado anteriormente, uma vez que elas são colocadas em pedidos de fechaduras concedidas e em fila de espera, respectivamente. A ordenação dos detentores na lista é importante. Se houver algum detentor concedido, ele estará sempre à frente da fila, seguido por qualquer detentor em fila de espera.

Se não houver titulares concedidos, então o primeiro titular na lista será aquele que desencadeará a próxima mudança de estado. Como os pedidos de demote são sempre considerados mais prioritários que os pedidos do sistema de arquivos, isso pode nem sempre resultar diretamente em uma mudança no estado solicitado.

O subsistema glock suporta dois tipos de fechadura "try". Estes são úteis tanto porque permitem a retirada de bloqueios fora da ordem normal (com recuo e tentativa adequados) e porque podem ser usados para ajudar a evitar recursos em uso por outros nós. A fechadura t (try) normal é exatamente o que seu nome indica; é uma fechadura "try" que não faz nada de especial. A fechadura T (try 1CB), por outro lado, é idêntica à fechadura t, exceto que a DLM enviará uma única chamada de retorno para os atuais porta-fechaduras incompatíveis. Um uso da fechadura T (try 1CB) é com as fechaduras iopen, que são usadas para arbitrar entre os nós quando a contagem do inode i_nlink é zero, e determinar qual dos nós será responsável pela desalocação do inode. A glock iopen é normalmente mantida no estado compartilhado, mas quando a contagem de i_nlink se torna zero e →evict_inode() é chamada, ela solicitará uma fechadura exclusiva com o conjunto T (try 1CB). Ela continuará a desalocar o inode se a fechadura for concedida. Se a eclusa não for concedida, resultará no(s) nó(s) que estava(m) impedindo a concessão da eclusa marcando seu(s) glock(s) com a bandeira D (demote), que é verificada em →drop_inode() tempo, a fim de garantir que a desalocação não seja esquecida.

Isto significa que os nós que têm contagem zero de ligações, mas ainda estão abertos, serão desalocados pelo nó em que o final close() ocorre. Além disso, ao mesmo tempo em que a contagem de links do inodo é decretada a zero, o inodo é marcado como estando no estado especial de ter contagem zero de links, mas ainda em uso no bitmap do grupo de recursos. Isto funciona como a lista de órfãos do sistema de arquivos ext3, pois permite que qualquer leitor subseqüente do bitmap saiba que existe um espaço potencial que pode ser recuperado, e tente recuperá-lo.

Os tracepoints também são projetados para poder confirmar a exatidão do controle do cache, combinando-os com a saída do blktrace e com o conhecimento do layout do on-disk. É então possível verificar se uma determinada E/S foi emitida e completada sob a trava correta, e se não há corridas presentes.

O traço gfs2_glock_state_change é o mais importante para entender. Ele rastreia cada mudança de estado da glóculo desde a criação inicial até a despromoção final que termina com gfs2_glock_put e o NL final para a transição desbloqueada. A bandeira l (bloqueada) da glock é sempre colocada antes que ocorra uma mudança de estado e só será liberada depois de terminada. Nunca há nenhum detentor concedido (a bandeira H glock holder) durante uma mudança de estado. Se houver algum detentor em fila de espera, ele estará sempre no estado W (em espera). Quando a mudança de estado estiver completa, os titulares poderão ser concedidos, o que é a operação final antes que a bandeira de glock l seja liberada.

O ponto de rastreamento gfs2_demote_rq mantém o controle dos pedidos de demote, tanto locais quanto remotos. Assumindo que haja memória suficiente no nó, os pedidos de demote local raramente serão vistos, e na maioria das vezes eles serão criados por umount ou ocasionalmente por recuperação de memória. O número de solicitações de demote remoto é uma medida da contenda entre nós para um determinado inode ou grupo de recursos.

O ponto de rastreamento gfs2_glock_lock_time fornece informações sobre o tempo gasto pelos pedidos ao DLM. A bandeira de bloqueio (b) foi introduzida na glock especificamente para ser usada em combinação com este tracepoint.

Quando um detentor recebe uma fechadura, gfs2_promote é chamado, isso ocorre como o estágio final de uma mudança de estado ou quando é solicitada uma fechadura que pode ser concedida imediatamente devido ao estado de glock já cravando uma fechadura de um modo adequado. Se o suporte for o primeiro a ser concedido para esta glock, então a bandeira f (primeira) é colocada nesse suporte. Isto é usado atualmente apenas por grupos de recursos.

O mapeamento de blocos é uma tarefa central para qualquer sistema de arquivos. O GFS2 utiliza um sistema tradicional baseado em bitmap com dois bits por bloco. O objetivo principal dos pontos de rastreamento neste subsistema é permitir o monitoramento do tempo necessário para alocar e mapear blocos.

O ponto de rastreamento gfs2_bmap é chamado duas vezes para cada operação de bmap: uma no início para exibir o pedido de bmap, e outra no final para exibir o resultado. Isto facilita a correspondência das solicitações e resultados juntos e mede o tempo necessário para mapear blocos em diferentes partes do sistema de arquivos, diferentes compensações de arquivos, ou mesmo de arquivos diferentes. Também é possível ver quais são os tamanhos médios de extensão que estão sendo devolvidos em comparação aos que estão sendo solicitados.

O gfs2_rs tracepoint traça reservas de blocos à medida que são criados, utilizados e destruídos no alocador de blocos.

Para manter o controle dos blocos alocados, gfs2_block_alloc é chamado não apenas nas alocações, mas também na liberação de blocos. Como as alocações são todas referenciadas de acordo com o inode ao qual o bloco é destinado, isto pode ser usado para rastrear quais blocos físicos pertencem a quais arquivos em um sistema de arquivos ao vivo. Isto é particularmente útil quando combinado com blktrace, que mostrará padrões de E/S problemáticos que podem então ser referidos de volta aos inodes relevantes usando o mapeamento obtido por meio deste tracepoint.

Direct I/O (iomap) é uma política de cache alternativa que permite que as transferências de dados de arquivos aconteçam diretamente entre o disco e o buffer do usuário. Isto tem benefícios em situações em que se espera que a taxa de acerto do cache seja baixa. Tanto gfs2_iomap_start como gfs2_iomap_end tracepoints rastreiam essas operações e podem ser usados para acompanhar o mapeamento usando Direct I/O, as posições no sistema de arquivo do Direct I/O junto com o tipo de operação.

Os pontos de rastro neste subsistema são adicionados e removidos do diário (gfs2_pin), bem como o tempo necessário para comprometer as transações com o diário (gfs2_log_flush). Isto pode ser muito útil ao tentar depurar questões de desempenho do periódico.

O ponto de rastreamento gfs2_log_blocks mantém registro dos blocos reservados no tronco, o que pode ajudar a mostrar se o tronco é muito pequeno para a carga de trabalho, por exemplo.

O traço gfs2_ail_flush é semelhante ao traço gfs2_log_flush, na medida em que mantém o controle do início e do fim dos fluxos da lista AIL. A lista AIL contém buffers que já passaram pelo log, mas ainda não foram escritos de volta no lugar e isto é periodicamente lavado a fim de liberar mais espaço de log para uso pelo sistema de arquivo, ou quando um processo solicita um sync ou fsync.

O GFS2 mantém estatísticas que podem ajudar a rastrear o que está acontecendo dentro do sistema de arquivos. Isto permite detectar problemas de desempenho.

O GFS2 mantém dois balcões:

Além disso, o GFS2 mantém três pares de média/variância. Os pares de média/variância são estimativas exponenciais suavizadas e o algoritmo utilizado é o utilizado para calcular os tempos de ida e volta em código de rede.

Os pares de média e variância mantidos no GFS2 não são escalados, mas estão em unidades de nanossegundos inteiros.

Um pedido sem bloqueio é aquele que será concluído imediatamente, qualquer que seja o estado da fechadura DLM em questão. Isso significa atualmente qualquer solicitação quando (a) o estado atual da fechadura é exclusivo (b) o estado solicitado é nulo ou desbloqueado ou (c) a bandeira "try lock" é colocada. Um pedido de bloqueio cobre todos os outros pedidos de bloqueio.

Tempos maiores são melhores para os IRTTs, enquanto que tempos menores são melhores para os RTTs.

As estatísticas são mantidas em dois arquivos sysfs:

Para mais informações sobre tracepoints e o arquivo GFS2 glocks, consulte os seguintes recursos:

Para operar corretamente, o GFS2 PMDA requer que o sistema de arquivo debugfs esteja montado. Se o sistema de arquivo debugfs não estiver montado, execute os seguintes comandos antes de instalar o GFS2 PMDA:

# mkdir /sys/kernel/debug
# mount -t debugfs none /sys/kernel/debug

O GFS2 PMDA não está habilitado como parte da instalação padrão. Para fazer uso do monitoramento métrico GFS2 através do PCP, você deve habilitá-lo após a instalação.

Execute os seguintes comandos para instalar o PCP e habilitar o GFS2 PMDA. Note que o script de instalação do PMDA deve ser executado como root.

# yum install pcp pcp-pmda-gfs2
# cd /var/lib/pcp/pmdas/gfs2
# ./Install
Updating the Performance Metrics Name Space (PMNS) ...
Terminate PMDA if already installed ...
Updating the PMCD control file, and notifying PMCD ...
Check gfs2 metrics have appeared ... 346 metrics and 255 values

A ferramenta pminfo exibe informações sobre as métricas de desempenho disponíveis. As seções seguintes mostram exemplos de diferentes métricas GFS2 que você pode exibir com esta ferramenta.

# pminfo -f gfs2.glocks

gfs2.glocks.total
    inst [0 or "afc_cluster:data"] value 43680
    inst [1 or "afc_cluster:bin"] value 2091

gfs2.glocks.shared
    inst [0 or "afc_cluster:data"] value 25
    inst [1 or "afc_cluster:bin"] value 25

gfs2.glocks.unlocked
    inst [0 or "afc_cluster:data"] value 43652
    inst [1 or "afc_cluster:bin"] value 2063

gfs2.glocks.deferred
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glocks.exclusive
    inst [0 or "afc_cluster:data"] value 3
    inst [1 or "afc_cluster:bin"] value 3

# pminfo -f gfs2.glstats

gfs2.glstats.total
    inst [0 or "afc_cluster:data"] value 43680
    inst [1 or "afc_cluster:bin"] value 2091

gfs2.glstats.trans
    inst [0 or "afc_cluster:data"] value 3
    inst [1 or "afc_cluster:bin"] value 3

gfs2.glstats.inode
    inst [0 or "afc_cluster:data"] value 17
    inst [1 or "afc_cluster:bin"] value 17

gfs2.glstats.rgrp
    inst [0 or "afc_cluster:data"] value 43642
    inst [1 or "afc_cluster:bin"] value 2053

gfs2.glstats.meta
    inst [0 or "afc_cluster:data"] value 1
    inst [1 or "afc_cluster:bin"] value 1

gfs2.glstats.iopen
    inst [0 or "afc_cluster:data"] value 16
    inst [1 or "afc_cluster:bin"] value 16

gfs2.glstats.flock
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glstats.quota
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glstats.journal
    inst [0 or "afc_cluster:data"] value 1
    inst [1 or "afc_cluster:bin"] value 1

# pminfo -f gfs2.holders.flags.wait

gfs2.holders.flags.wait
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

# pmstore gfs2.control.tracepoints.all 1
gfs2.control.tracepoints.all old value=0 new value=1

# pminfo -f gfs2.latency.grant.all gfs2.latency.demote.all

gfs2.latency.grant.all
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.latency.demote.all
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.latency.grant.all gfs2.latency.demote.all

gfs2.tracepoints.promote.other.null_lock
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.concurrent_read
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.concurrent_write
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.protected_read
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.protected_write
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.exclusive
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.tracepoints.demote_rq.requested

gfs2.tracepoints.demote_rq.requested.remote
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.demote_rq.requested.local
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.tracepoints.log_flush.total

gfs2.tracepoints.log_flush.total
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

Tabela 9.1, “Lista métrica completa” descreve a lista completa das métricas de desempenho fornecidas pelo pacote pcp-pmda-gfs2 para os sistemas de arquivos GFS2.

O procedimento a seguir descreve instruções sobre como instalar uma configuração mínima de PCP para coletar estatísticas sobre o Red Hat Enterprise Linux. Esta configuração envolve a adição do número mínimo de pacotes em um sistema de produção necessários para coletar dados para análise posterior.

O arquivo tar.gz resultante da produção do pmlogger pode ser analisado usando ferramentas adicionais de PCP e pode ser comparado com outras fontes de informação de desempenho.