Qual é o comportamento de exclusão de arquivo esperado em um SMR controlado por dispositivo?

Question

Os drives SMR parecem ser os melhores para escrever uma vez, lendo várias vezes. Eu tenho um número significativo de estruturas de diretórios duplicados hardlink armazenados em um dispositivo SMR e desejei excluir o mais recente, no entanto, o processo parece ser dolorosamente lento. Ou houve uma falha ou este é um comportamento esperado.

Eu posso imaginar várias razões pelas quais isso pode ser, existe informação concreta para explicar isso?

Pensamentos:

1. A atualização da tabela de arquivos requer a modificação das partes iniciais do disco que precisam de reescrita significativa dos dados, conforme as regras de reescrita do SMR.
2. Arquivos vinculados exigem atualizações de contagem de referência que estão modificando a tabela de arquivos, novamente exigindo uma reescrita significativa dos dados.

Mais geralmente, como funciona um sistema de arquivos no SMR com eficiência? Os dados são distribuídos pelo disco, mas a tabela de arquivos deve ser mantida separada, caso contrário, o shingling eliminará o desempenho. Como uma unidade gerenciada pelo SMR sabia onde a tabela de arquivos lidava com isso de alguma maneira especial? Alguns sistemas de arquivos são melhores que outros nesse caso?

Específicos: Drive: Seagate Archive 6TB SO: kernel do CentOS 7 3.10.0 Sistema de arquivos: BTRFS Uso do drive: 66%

    

Answer 1

O BTRFS é copy on write (CoW), o que significa que (em geral) os blocos de dados são muito fragmentados (eu uso o ZFS, o mesmo problema), incluindo a tabela de arquivos.

Provavelmente, todos os setores que são modificados afetam toda uma unidade shingled, e isso explica por que você vê as terríveis performances: você está escrevendo, por exemplo, 10 blocos de dados (10x4 = 40 KiB)? devido à falta de localidade, você pode, de fato, ler 10x10 MiB (40 MiB) e depois escrever outros 40 MiB. Acrescente o fato de que há latência de busca em várias etapas do processo, e os desempenhos são mortos.

Provavelmente nenhuma solução, exceto a comutação para um drive não-SMR ou para um sistema de arquivos não-CoW.

Editar : informações adicionais link (sistemas de arquivos compatíveis com SMR)

link "O HGST está utilizando Bandas de 256MB em suas ofertas inaugurais. A Seagate indica que os tamanhos das bandas são ajustáveis para cargas de trabalho e aplicativos de drives personalizados "então você está lendo e escrevendo potencialmente 256 MiB por cada setor (4 KiB) que você modifica.