Diferenças entre o sistema de arquivos tradicional e o Oracle Solaris ZFS

• Granularidade do sistema de arquivos ZFS

• Contabilidade de espaço em disco do ZFS

• Montando sistemas de arquivos ZFS

• Gerenciamento de volume tradicional

• Modelo de ACL do Solaris Baseado em NFSv4

Granularidade do sistema de arquivos ZFS

Historicamente, sistemas de arquivos foram restritos a um único dispositivo e, com isso, para o tamanho desse dispositivo. A criação e recriação de sistemas de arquivos tradicionais, devido às restrições do tamanho, exigem muito tempo e são muitas vezes difíceis. Os produtos de gerenciamento de volume tradicionais ajudaram a gerenciar este processo.

Por não estarem limitados a dispositivos específicos, os sistemas de arquivos ZFS podem ser criados rápida e facilmente, semelhante à criação de diretórios. Os sistemas de arquivos do ZFS crescem automaticamente dentro do espaço em disco alocado para o pool de armazenamento no qual residem.

Em vez de criar um sistema de arquivos, como o /export/home, para gerenciar vários subdiretórios de usuários, você pode criar um sistema de arquivos por usuário. É possível configurar e gerenciar facilmente muitos sistemas de arquivos aplicando propriedades que podem ser herdadas pelos sistemas de arquivos descendentes contidos na hierarquia.

Para ver um exemplo de como criar uma hierarquia de sistema de arquivos, consulte Criando uma hierarquia de sistemas de arquivos ZFS.

Contabilidade de espaço em disco do ZFS

O ZFS é baseado no conceito de armazenamento em pools. Ao contrário dos típicos sistemas de arquivos, que são mapeados para armazenamentos físicos, todos os sistemas de arquivos ZFS de um pool compartilham o armazenamento disponível no pool. Desse modo, o espaço disponível relatado por utilitários como o df pode alterar mesmo quando o sistema de arquivos está inativo, já que outros sistemas de arquivos do pool consomem e liberam espaço.

Observe que o tamanho máximo do sistema de arquivos pode ser limitado pelo uso de cotas. Para obter mais informações sobre as cotas, consulte Definindo cotas em sistemas de arquivos ZFS. Uma quantidade especificada de espaço em disco pode ser garantida para um sistema de arquivos utilizando as reservas. Para obter mais informações sobre as reservas, consulte Definindo reservas nos sistemas de arquivos ZFS. Esse modelo é semelhante ao modelo de NFS, no qual vários diretórios são montados a partir do mesmo sistema de arquivos (considerar /home).

Todos os metadados no ZFS estão alocados dinamicamente. A maioria dos outros sistemas de arquivos pré-alocam muitos de seus metadados. Como resultado, na hora da criação do sistema de arquivos, há um custo imediato de espaço para esses metadados. Esse comportamento denota também que o número total de arquivos suportado pelos sistemas de arquivos é predeterminado. Por alocar seus metadados conforme precisa deles, o ZFS não requer quantidade de espaço inicial, e o número de arquivos está limitado somente pelo espaço em disco disponível. A saída do comando df -g não deve ser interpretada da mesma forma para o ZFS e para outros sistemas de arquivos. Os arquivos totais relatados são somente uma estimativa baseada na quantidade de armazenamento disponível no pool.

O ZFS é um sistema de arquivos transacional. A maioria das modificações do sistema de arquivos é incorporada dentro de grupos transacionais e é enviada ao disco assincronicamente. Antes de estarem comprometidas com o disco, essas modificações são denominadas alterações pendentes. A quantidade de espaço utilizado, disponível e referenciada pelo arquivo ou sistema de arquivos não considera as alterações pendentes. As alterações pendentes são consideradas em geral depois de alguns segundos. Mesmo comprometendo uma alteração no disco utilizando fsync(3c) ou O_SYNC, isso não garante necessariamente que as informações sobre o uso do espaço em disco sejam atualizadas imediatamente.

Em um sistema de arquivos UFS, o comando du reporta o tamanho do bloco de dados no arquivo. Em um sistema ZFS, du reporta o tamanho real do arquivo como armazenado no disco. Esse tamanho inclui metadados e compactação. Esse relatório ajuda a responder "quanto mais de espaço obterei se remover este arquivo?" Portanto, mesmo quando a compactação está desativada, você ainda verá resultados diferentes entre ZFS e UFS.

Quando você compara o consumo do espaço que é reportado pelo comando df com o comando zfs list, considere que df está reportando o tamanho do pool e não apenas os tamanhos dos sistemas de arquivos. Além disso, df não entende sistemas de arquivo descendentes ou se existem instantâneos. Se alguma propriedade de ZFS, como compactação e cotas, for definida nos sistemas de arquivos, a reconciliação de consumo de espaço reportada pelo df poderá ser difícil.

Considere os seguintes cenários que também podem afetar o consumo de espaço informado:

• Para os arquivos maiores que recordsize, o último bloco de arquivos geralmente fica metade cheio. Com o recordsize padrão definido como 128 KB, aproximadamente 64 KB são perdidos por arquivo, o que pode ser um grande impacto. A integração de RFE 6812608 resolve este cenário. Você pode solucionar isso ativando a compactação. Mesmo se seus dados já estiverem compactados, a parte não usada do último bloco será preenchida com zeros e a compactação será muito boa.

• Em um pool RAIDZ-2, cada bloco consome pelo menos 2 setores (porções de 512 bytes) de informações de paridade. O espaço consumido pelas informações de paridade não é reportado, mas como pode variar e ser uma porcentagem muito maior para blocos pequenos, talvez seja observado um impacto no relatório de espaços. O impacto é mais extremo para um recordsize definido como 512 bytes, em que cada bloco lógico de 512 bytes consome 1,5 KB (3 vezes o espaço). Independentemente dos dados que estão sendo armazenados, se a eficiência de espaço for sua principal preocupação, você deve manter o recordsize como padrão (128 KB) e ativar a compactação (para o padrão de lzjb).

• O comando df não conhece os dados de arquivos desduplicados.

Comportamento por espaço excedido

Os instantâneos de sistemas de arquivos são baratos e fáceis de criar no ZFS. Os instantâneos são comuns na maioria dos ambientes do ZFS. Para obter informações sobre os instantâneos do ZFS, consulte o Capítulo 6, Trabalhando com instantâneos e clones do Oracle Solaris ZFS.

A presença de instantâneos pode provocar alguns comportamentos inesperados ao tentar liberar espaço em disco. Normalmente, com as permissões apropriadas, é possível remover um arquivo de todo um sistema de arquivos, e esta ação resulta em mais espaço em disco disponível no sistema de arquivos. No entanto, se o arquivo a ser removido existir no instantâneo do sistema de arquivos, então nenhum espaço em disco é liberado com a exclusão do arquivo. Os blocos usados pelo arquivo continuam a ser referenciados a partir do instantâneo.

Como resultado, a exclusão do arquivo pode consumir mais espaço em disco, pois uma nova versão do diretório precisa ser criada para refletir o novo estado do espaço de nome. Este comportamento significa que é possível receber um erro ENOSPC ou EDQUOT inesperado ao tentar remover o arquivo.

Montando sistemas de arquivos ZFS

O ZFS reduz a complexidade e facilita a administração. Por exemplo, com sistemas de arquivos tradicionais, você deve editar o arquivo /etc/vfstab sempre que um novo sistema de arquivos for adicionado. O ZFS eliminou essa necessidade montando e desmontando automaticamente os sistemas de arquivos de acordo com as propriedades do sistema de arquivos. Você não precisa gerenciar as entradas do ZFS no arquivo /etc/vfstab.

Para obter mais informações sobre a montagem e o compartilhamento de sistemas de arquivos ZFS, consulte Montando sistemas de arquivos ZFS.

Gerenciamento de volume tradicional

De acordo com o descrito em Armazenamento de ZFS em pool, o ZFS dispensa a necessidade de usar um gerenciador de volumes diferente. O ZFS opera em dispositivos básicos, de modo que é possível criar um pool de armazenamento constituído de volumes lógicos, tanto no software quanto no hardware. Essa configuração não é recomendada, já que o ZFS funciona melhor quando usa dispositivos físicos básicos. O uso de volumes lógicos pode prejudicar o desempenho, a segurança, ou ambos, e deve ser evitado.

Modelo de ACL do Solaris Baseado em NFSv4

As versões anteriores do sistema operacional Solaris ofereciam suporte a uma implementação de ACL baseada principalmente na especificação da ACL do esquema POSIX. As ACLs baseadas no esquema POSIX são usadas para proteger os arquivos UFS. O novo modelo de ACL do Solaris com base na especificação NFSv4 é utilizado para proteger os arquivos do ZFS.

As principais diferenças do novo modelo da ACL do Solaris são as seguintes:

• O modelo tem base na especificação do NFSv4 e é similar às ACLs de estilo NT.

• Este modelo fornece um conjunto de privilégios de acesso mais granular.

• ACLs são definidas e exibidas com os comandos chmod e ls em vez dos comandos setfacl e getfacl .

• Semânticas mais ricas designam como os privilégios de acesso são aplicados do diretório aos subdiretórios, e assim por diante.

Para obter mais informações sobre o uso de ACLs com arquivos do ZFS, consulte o Capítulo 7, Uso de ACLs e atributos para proteger arquivos do Oracle Solaris ZFS.