Melhoraria o desempenho de gravação para preencher uma unidade reformatada com zeros?

14

Eu tenho uma unidade de 2 TB que foi preenchida para> 99%. Eu apaguei as partições fidske as formatei mkfs.ext4.

Até onde eu sei, os dados reais que estavam na unidade ainda existem. Ainda a tabela de partição foi reatribuída.

A pergunta é: Melhoraria o desempenho de gravação para ações de gravação adicionais se o disco fosse limpo ? Com limpo, quero dizer encher o disco com zeros?

Algo como

dd if=/dev/zero of=/dev/sdx bs=1 count=4503599627370496
Brettetete
fonte
8
Não há vantagem em ter zero para começar, pois ele substituirá qualquer coisa que esteja lá para começar.
Moab
7
Se fosse um SSD, a resposta seria "inferno não", porque o mkfs.ext4 realmente usa o TRIM para descartar todo o conteúdo da partição, portanto, escrever manualmente zeros em cima disso reduziria levemente o desempenho.
user1686
2
@rawity Tenho me perguntado se existe algum SSD que automaticamente transforma gravações de todos os zeros em TRIM.
kasperd
@ Kasperd: boa pergunta de acompanhamento!
liori 17/10/2015
Outra possível pergunta de acompanhamento: se o disco fosse uma VM montada em uma SAN que executasse uma duplicação de disco de baixo nível, isso poderia ajudar (se os dados foram excluídos no nível da VM, a menos que o sistema esteja usando alguma API compatível com VM , verificaria à SAN que todos esses blocos excluídos precisariam ficar por perto, enquanto defini-los com todos os zeros acabaria com um monte de blocos duplicados, todos apontados para uma coisa totalmente zero)
Foon

Respostas:

36

Não, isso não melhoraria o desempenho.

TL; DR: as unidades de disco rígido magnéticas rotacionais não funcionam assim.

Primeiro, quando você grava dados em uma unidade de armazenamento magnético rotacional, esses dados são transformados em domínios magnéticos que podem realmente parecer muito diferentes do padrão de bits que você está gravando. Isso é feito em parte porque é muito mais fácil manter a sincronização quando o padrão lido de volta no prato tem uma certa quantidade de variabilidade e, por exemplo, uma longa sequência de valores "zero" ou "um" dificultaria muito a manutenção da sincronização. . (Você leu 26.393 bits ou 26.394 bits? Como você reconhece a fronteira entre os bits?) As técnicas para fazer essa transformação entre bits de dados de computador e pedaços armazenáveis ​​evoluíram com o tempo; por exemplo, procure Modulação de frequência modificada , MMFM,Gravação de código de grupo e a tecnologia mais geral de codificações limitadas na execução .

O processo de gravação real, como HAMR , PMR , shingled e assim por diante, é ortogonal a isso, pois descreve a mecânica de como os domínios magnéticos são armazenados na mídia física.

Segundo, quando você escreve novos dados em um setor, os domínios magnéticos das partes relevantes do prato são simplesmente configurados para o valor desejado. Isso é feito independentemente do domínio magnético anterior naquele local físico específico. O prato já está girando sob a cabeça de gravação; ler primeiro o valor atual e depois escrever o novo valor, se e somente se for diferente, fará com que cada gravação exija duas rotações (ou um cabeçote extra para cada prato), fazendo com que a latência de gravação duplique ou aumente bastante a complexidade da unidade, por sua vez, aumentando o custo. Como o fator limitante no desempenho de E / S sequencial do disco rígido é a rapidez com que cada bit passa sob o cabeçote de leitura / gravação, isso não oferece nenhum benefício ao usuário. (Como um aparte, o fator limitante no desempenho aleatório de E / S é a rapidez com que a cabeça de leitura / gravação pode ser posicionada no cilindro desejado e, em seguida, o setor desejado chega sob a cabeça. A principal razão pela qual os SSDs podem ser tão rápidos em cargas de trabalho de E / S aleatórias é que eles eliminam completamente esses dois fatores.)

Conforme apontado por JakeGould , uma das razões pelas quais você pode sobrescrever a unidade com algum padrão fixo (como todos os zeros) seria garantir que nenhum remanescente de dados armazenados anteriormente possa ser recuperado , deliberada ou acidentalmente. Mas fazer isso não afetará o desempenho da unidade daqui para frente, pelas razões expostas acima. Outro motivo, que se pode dizer que "melhora o desempenho", como apontado por liori , é ajudar a compactar partes não utilizadas das imagens de disco armazenadas, mas mesmo isso não melhora o desempenho do sistema em uso.

um CVn
fonte
3
Outro motivo para zerar partições / unidades é se você planeja fazer o despejo bruto de partições / unidades (por exemplo, como um backup, criando uma imagem do sistema operacional para várias máquinas, como uma técnica de migração do sistema etc.). Os zeros são compactados bem, o que pode ser diferente do conteúdo anterior armazenado na unidade.
Liori
@ liori Bom ponto, mas esse não é um cenário comum para o usuário final e está bem longe do que o OP está descrevendo.
um CVn
Então os discos ópticos são não rotacionais ou magnéticos?
Max Ried
4

Você diz o seguinte:

A pergunta é: Melhoraria o desempenho de gravação para ações de gravação adicionais se o disco fosse limpo? Com limpo, quero dizer encher o disco com zeros?

100% não. Gravar zeros em um disco não melhora o desempenho. Você faria isso apenas para destruir dados. Então, sabendo disso, você diz o seguinte:

Até onde eu sei, os dados reais que estavam na unidade ainda existem.

Tecnicamente sim ... Os dados que existiam anteriormente na unidade ainda existem na unidade em algum nível fundamental. Dito isso, ele não existe de uma forma fácil de acessar ou recuperar neste momento, mas pode ser uma preocupação se você estiver realmente preocupado com o comprometimento dos dados por alguém disposto a fazer um esforço para recuperar esses fragmentos de dados que permanecem.

Portanto, se a segurança e a privacidade são uma preocupação, convém gravar zeros na unidade para garantir que todo o espaço livre seja realmente limpo. Mas segurança e privacidade são a única razão absoluta para você eliminar o espaço livre com zeros, pois fazer algo assim nunca melhora o desempenho.

JakeGould
fonte
A execução de uma ferramenta como recovernão conta como "fácil"? Isso geraria muitos arquivos em uma unidade completa que acabara de ser encontrada mkfs.
Hbbs #
0

Meu presente de dois centavos para todos vocês é minha própria experiência, SIM ajuda, mas com cautela.

Eu tinha muitos SSDs e, com base em meus próprios testes, recomendo preencher com zeros antes de reescrever a tabela mestre e, em vez de excluir partições, recriar a tabela mestre.

Mais tarde explicarei o porquê, mas as etapas seriam necessárias para preencher todo o SSD, use bs = 1M, muito mais rápido que bs = 1, e esqueci o parâmetro count para fazê-lo ir até o fim (isso dará o erro de não haver mais espaço quando chegue ao fim, que está marcado, então não se preocupe em ver esse erro, ele deve ser mostrado); após o preenchimento completo, use gparted ou o que você quiser gravar uma tabela mestre (MBR / GPT / etc), conforme necessário, isso 'aparará' todo o disco e criará partições com o formato desejado, etc.

Por que preenchê-lo com zeros? Uma resposta curta é que minha experiência é quando eu o preencho com zeros, alguns SSDs que, onde dar 2-24 blocos ilegíveis foram corrigidos, não existem mais blocos inacessíveis.

Agora, a primeira coisa que faço quando recebo um novo SSD, antes de usá-lo, é preenchê-lo com zeros, para garantir que não sofra novamente os erros aleatórios comuns de blocos de 1KiB ilegíveis.

Minha experiência: Usando o software para ler / testar todo o SSD (informa quanto tempo leva para ler cada 'setor') eu estava recebendo muitos pares de 'setores de 512 bytes' (blocos de 1 KiB) inacessíveis e sua posição muda aleatoriamente e o número de falhas varia de 2 a 24, etc .; após o preenchimento completo com zeros e recrie a tabela principal (que elimina o corte), não mais setores ilegíveis.

Meu teste de colisão: em vez de preencher com zeros para recuperar esses erros, deixei que um SSD fosse usado, depois de algumas horas e com apenas menos de um terabyte gravado nele (SSD de 120GiB), ele morreu de maneira perdida, não permite acesso a ele mais, a bios da placa-mãe não pode vê-lo, os gabinetes USB congelam ao acessá-lo, de modo que nem o Windows a vê, nem o Linix fdisk a vê.

Foi um teste de 'morrer' com vários SSDs que eu tinha comprado ao mesmo tempo, idênticos ... tudo o que eu não zerou foram mortos, o resto tem muitos blocos realocados, mas sem mais erros ilegíveis.

Obviamente, minha conclusão é que nem todos os SSDs são confiáveis, independentemente da marca e capacidade.

Então, a primeira coisa com eles, na minha experiência, é forçá-los a preencher pelo menos uma vez, melhor com zeros do que com aleatório (é mais rápido).

Além disso, a maioria dos SSD faz ajustes internos quando escritos com zeros (algoritmos de lembrança, etc.).

Além disso, se você os preencher pela primeira vez, qualquer bloco que apresentar erro de gravação será realocado. É muito melhor que isso aconteça sem dados vitais, quando zeros escritos se os dados foram perdidos (todos eram zeros), isso não é relevante, mas se os dados são 'vitais' para o sistema operacional, é muito ruim.

A maioria das realocações de SSD faz isso, mas perdendo os dados no bloco que deu erro de gravação, apenas 'enterprise' (eles custam> 10 € por GiB) faz uma nova tentativa de gravação após realocar corretamente. Alguns SSD também perderão todos os outros 'setores' nesse bloco com falha (como fazer um 'descarte').

Portanto, tente primeiro, após o preenchimento completo, verifique os dados SMART para ver quantas realocações ainda podem ser feitas.

Não é tão importante quanto as realocações foram feitas, a maioria dos SSDs veio do fabricante com alguns blocos já realocados; encontre um com zero menor que 1%;

É a minha experiência depois que centenas de SSDs morreram ao longo de cinco e cinco anos, alguns morreram na primeira hora de uso, outros em uma semana, outros em um mês; mas tudo o que fiz como zero preenchimento completo permaneceu por 2 a 3 anos, com um 13GiB escrito a cada dia, 3 * 365 * 13 GiB = 13,9TiB escrito, muito menos do que dizem as manufaturas (> 100TiB).

Mas a velocidade é importante, principalmente no Windows (no Linux, uma boa distribuição 2xHDD LVM2 oferece os mesmos tempos de inicialização, mas não falha em> 25 anos), portanto, usar SSD com um preço de 0,21 € por Gigabyte (120GiB = 25 €) é vale a pena (para Windows), entre eles podem ser alterados após 2 ou 3 anos; Espero que a tecnologia melhore a confiabilidade.

Para Linux, não quero mais SSD até que seja mais confiável, mas para Windows (Vista, 7 e 10) a partição do sistema é obrigatória (vezes de inicialização dez vezes menor em alguns casos, com o Windows Vista, em vez de> 30min inicializá-lo inicialize> 4min no meu laptop antigo).

Sim, preenchimento completo com zeros é uma obrigação, dada a minha experiência.

Mas, somente quando você recebe o SSD e antes de usá-lo para qualquer coisa.

Dica: Se o SSD não executar bem a coleta de lixo e o sistema operacional não solicitar que apare tudo, é melhor fazer um preenchimento completo com zeros, no final, é isso que ocorre internamente no SSD ao descartar blocos. A gravação de zeros também será limpa eletrônica, por isso ajuda a recuperar blocos de leitura com falha.

Além disso, toda vez que você alterar os dados, tente fazer um clone, o SSD informará que a gravação está OK, também em setores ilegíveis (eles podem ser gravados OK, mas não lidos), nenhum sistema operacional foi projetado para suportar essa condição , todos eles supõem se wtite está OK, os dados podem ser lidos; não confunda legível com dados diferentes lidos e thsn o que foi escrito.

Essa é a minha experiência com SSDs e HDDs. Para aplicativos e inicialização do Windows, eu uso o SSD, mas sempre com um clone feito em HDDs normais, já que o SSD morre em menos de 3 anos, mas o gor Linux eu uso o HDD 2x ou 3x bom de 2,5 "ti obtém tempos semelhantes no uso normal do que o SSD daria , mas com duração muito maior (> 25 anos).

Eu não estou disposto a pagar> 1000 € pelo SSD corporativo de 100GiB que funciona bem por 10 anos, prefiro pagar 25 € por 130GiB a cada 2 ou 3 anos. O preço importa 100 € por ano (empresa) versus 10 € por ano (Yucon, Samsung, etc), basta fazer as contas.

Claudio
fonte
Forçar a escrever sobre setores defeituosos é de fato uma maneira bastante confiável de "consertá-los", desde que ainda haja setores reservados disponíveis.
Confetti