O formato rápido do LUN no Servidor 2012 (R2) hospedado em um SAN vol. provisionado thin demora

Question

Eu já experimentei esse problema com três fornecedores de armazenamento diferentes, usando três adaptadores CNA diferentes (todos com FCoE), então estou certo de que esse problema não está isolado para um fornecedor de armazenamento específico (visto no HP 3PAR, EMC VNX e HDS G1000 ().

Quando adicionamos um thin LUN provisionado a um host (conectado via FCoE, MPIO instalado) e formatamos rapidamente o LUN (NTFS), leva 30 minutos para o formato ser concluído. Eu encontrei outros tópicos que mencionam esta questão - mas até agora eu ainda não encontrei uma solução / explicação. Até agora nós só tivemos que viver com isso, mas é muito chato devo dizer. Não parece estar relacionado com o tamanho do LUN - 100GB ou 2TB, ainda leva 20-30mins para o formato QUICK a unidade! Isso é mais como o formato SLOW no meu livro.

Alguém mais vendo isso / tem uma explicação? Eu vi isso no Windows Server 2012 (R2) até agora - não testado em 2008 (R2).

    

Answer 1

Eu finalmente encontrei algum tempo para examinar essa questão - e minhas suspeitas iniciais provaram estar certas: ela está relacionada ao TRIM / UNMAP, que é ativado por padrão no Server 2012 (R2).

Eu tentei conectar um novo SAN LUN de 2TB a um host e emiti o comando:

conjunto de comportamento do fsutil DisableDeleteNotify 1

• Antes de começar o formato rápido. Formato agora levou < 1 min.

Não tenho certeza se é uma boa idéia deixar o TRIM desabilitado, então, por enquanto, vou ativá-lo novamente, depois de ter formatado todos os meus LUNS.

conjunto de comportamento do fsutil DisableDeleteNotify 0

Pensando um pouco depois: lembro-me de um cenário, em que tivemos que desativar o TRIM completamente em uma máquina física também: um servidor de consolidação de logs. Os logs não compactados foram movidos para essa máquina (com um SAN LUN provisionado thin). Os logs foram então comprimidos. O desempenho na unidade foi horrível durante as compressões - até que desligamos o TRIM.

Portanto, parece que algo está errado nas comunicações entre o Windows Server e o SAN. É claro que o Windows sabe que o SAN vol suporta o trim (porque não vemos esse problema em nosso SAN antigo, que NÃO suporta o trim).

    

Answer 2

Eu tive um problema semelhante com volumes lógicos thinly provisioned e sistema de arquivos XFS.

Basicamente, o problema estava relacionado a como o XFS aloca seus metadados: ele grava alguns metadados, depois procura, aloca outros metadados e assim por diante. À medida que cada alocação de metadados aciona o volume thin subjacente para alocar um grupo de blocos de dados diferente, o processo se torna bastante lento.

Acho que seu cenário é bem parecido com isso, mesmo usando NTFS.