Pagina inicial » como » O desempenho da gravação melhoraria se um disco rígido reformatado fosse preenchido com zeros?

    O desempenho da gravação melhoraria se um disco rígido reformatado fosse preenchido com zeros?

    Se você for reformatar um disco rígido, há algo que "melhore" o desempenho de gravação depois ou é algo com o qual você não deveria se preocupar? O post de perguntas e respostas do SuperUser de hoje tem as respostas para as perguntas de um curioso leitor.

    A sessão de perguntas e respostas de hoje nos é oferecida por cortesia do SuperUser - uma subdivisão do Stack Exchange, um agrupamento de sites de perguntas e respostas conduzido pela comunidade..

    Foto cedida por Chris Bannister (Flickr).

    A questão

    Leitor SuperUser A Brettetete quer saber se o preenchimento de um disco rígido com zeros melhoraria o desempenho de gravação:

    Eu tenho um disco rígido de 2TB que estava 99% cheio. Eu apaguei as partições com fdisk e formatado como ext4. Até onde eu sei, os dados reais que estavam no disco rígido ainda existem, mas a tabela de partição foi reatribuída.

    Minha pergunta é: Melhoraria o desempenho de gravação para outras ações de gravação se o disco rígido estivesse limpo? Por 'limpo' quero dizer encher o disco rígido com zeros? Algo como:

    • dd se = / dev / zero de = / dev / sdx bs = 1 count = 4503599627370496

    Encher o disco rígido com zeros melhora o desempenho de gravação?

    A resposta

    Michael Kjörling, colaborador do SuperUser, tem a resposta para nós:

    Não, isso não melhoraria o desempenho. HDDs não funcionam assim.

    Primeiro, quando você escreve qualquer dado em uma unidade rotacional, ele é transformado em domínios magnéticos que podem realmente parecer muito diferentes do padrão de bits que você está escrevendo. Isso é feito em parte porque é muito mais fácil manter a sincronização quando o padrão lido do disco tem uma certa variabilidade. Por exemplo, uma cadeia longa de valores "zero" ou "um" tornaria muito difícil manter a sincronização. Você já leu 26.393 bits ou 26.394 bits? Como você reconhece o limite entre os bits?

    As técnicas para fazer isso evoluíram ao longo do tempo. Por exemplo, consulte Modulação de frequência modificada, MMFM, Gravação de código de grupo e a tecnologia mais geral de codificações limitadas de comprimento de execução.

    Em segundo lugar, quando você escreve novos dados em um setor, os domínios magnéticos das partes relevantes do disco são simplesmente definidos para o valor desejado. Isso é feito independentemente do que o domínio magnético anterior "estava" naquele local físico específico. O prato já está girando sob a cabeça de gravação; primeiro lendo o valor atual, depois escrevendo o novo valor se e somente se for diferente. Isso faria com que cada gravação exigisse duas revoluções (ou uma cabeça extra para cada prato), fazendo com que a latência de gravação dobrasse ou aumentasse consideravelmente a complexidade da unidade, 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 a cabeça de leitura / gravação, isso não ofereceria nenhum benefício ao usuário. Como um aparte, o fator limitante no desempenho de E / S aleatória é 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.

    Como apontado por JakeGould, uma razão pela qual você pode querer substituir a unidade com algum padrão fixo (como todos os zeros) seria garantir que nenhum resto de dados armazenados anteriormente possa ser recuperado, deliberadamente ou acidentalmente. Mas isso não afetará o desempenho do disco rígido, pelas razões expostas acima..


    Tem algo a acrescentar à explicação? Som desligado nos comentários. Quer ler mais respostas de outros usuários do Stack Exchange com experiência em tecnologia? Confira o tópico de discussão completo aqui.