Quais propriedades de pool ZFS, vdev e conjunto de dados a maioria das pessoas deve usar?

Question

ZFS tem muitas propriedades configuráveis ​​diferentespara piscinas,para vdevsepara conjuntos de dados. Muitos deles podem ser alterados a qualquer momento, mas alguns só podem ser definidos no momento da criação (ou afetam apenas os dados gravados posteriormente).deverealmente ser definido no momento da criação).

Como novato, pesquisei muitas perguntas diferentes e encontrei várias propriedades que foram sugeridas para serem definidas com frequência.

Obviamente, cada caso de uso terá pequenas diferenças sobre quais propriedades fazem sentido, mas parece haver um conjunto comum de propriedades que a maioria dos usuários do zfs deve usar. Estou pensando naquelas propriedades para as quais se deveria ter uma razão ativanãopara usá-los. O que são e por quê?

Answer 1

(Isenção de responsabilidade: como iniciante no ZFS, este é apenas o meu entendimento até agora e serve como um impulso para obter informações mais completas e confiáveis ​​de outras pessoas).

Propriedades da piscina

• ashift=12

  Em um nível básico issogarante que as operações de leitura/gravação do ZFS se alinhem com os limites de bloco do armazenamento subjacente.Teoricamentepara blocos de 512 bytes ashift=9seria bom, mas unidades com esses são raras atualmente e a penalidade por definir ashift"muito alto" é bastante baixa.

• autotrim=on

  Automaticamenteinformar o armazenamento de bloco subjacente quando algum espaço não for mais necessário. Especialmente útil em SSDs, mas também parece não prejudicar os HDDs clássicos (embora provavelmente não ajude nisso).

Propriedades do conjunto de dados

Eles podem ser especificados com zfs create -oou por meio da -Oopção zpool createdo sistema de arquivos raiz (que, por padrão, será herdado de outros).

• xattr=sa

  Isso aumenta significativamente o desempenho do xattr sem nenhuma desvantagem real. (Disponível apenas no Linuxpor agora).

• dnodesize=auto

  Esta propriedade deve ser usada ao usar xattr=sa. A principal razão para não usá-los éinteragindo com sistemas que não suportam o recurso ZFS necessário.

• relatime=on

  Rastrear o tempo de acesso dos arquivos pode ser muito caro, mesmo em interação somente leitura. relatimereduz significativamente a granularidade/frequência dessas atualizações ao custo de informações menos precisas na atimepropriedade (enquanto mantém algumas invariantes comumente exigidas). Observe que este é o padrão para quase todos os sistemas de arquivos no Linux há muito tempo. Se precisar de atimeinformações precisas, não ative isso. Se alguém souber que isso atimenunca será necessário, atime=offo desempenho será ainda melhor.

• normalization=formD

  Isso garantirá que os nomes dos arquivos sejam sempre normalizados da mesma maneira. Como um efeito colateral importante, isso também significa que o sistema de arquivos tratará os nomes dos arquivos como codificados em UTF-8 e não poderá mais armazenar nomes de arquivos com determinados nomes "quebrados" que outros sistemas de arquivos aceitam. Se isso não for desejado, deixe isso de fora.

• compression=lz4

  O consenso parece ser que o custo da compressão é tão baixo em hardware moderno que isso só tem vantagens. Os conjuntos de dados que armazenam predominantemente dados já altamente compactados podem querer desativar isso.

• nãorecordsize

  O tamanho do registro padrão parece ser um bom meio-termo para muitos casos de uso, mas alguns casos de uso, como bancos de dados, podem se beneficiar de valores específicos.

Fontes

• Raiz Debian no ZFS
• Muitas postagens individuais no fórum