Percebi que toda vez que copio uma grande quantidade de dados para o meu disco rígido, ele ainda está funcionando após o término da transferência do arquivo. Faz alguns sons como se ainda estivesse sendo escrito, como se estivesse desfragmentando.
Agora ele é colocado em um servidor Linux com Raspberry Pi, mas também antes, quando o conectamos ao laptop com Windows, ele fazia a mesma coisa. E eu não tinha nenhum programa de desfragmentação ativado... Quanto maior a quantidade de dados, mais tempo demora até parar de funcionar em... Deus sabe o quê. É um WD Blue 1TB conectado ao USB 3.0. Ele tem partição EXT4 no Linux e também tinha NTFS antes.
O que você acha que é isso? Devo ficar preocupado?
Dependendo do modelo específico do drive, ele pode estar usando a tecnologia SMR. A Gravação Magnética Shingled é uma tecnologia que pode aumentar a densidade dos dados gravados e fazer um uso mais eficaz do espaço físico na unidade, mas tem alguns custos.
O resultado líquido é o comportamento que você vê. A unidade aceita os dados aparentemente normalmente e depois gasta algum tempo reorganizando os dados no disco enquanto copia os dados da zona CMR para a zona SMR.
Meia hora parece excessivo, mas pode estar movendo os dados em pequenos pacotes ao longo do tempo para manter a interface da unidade disponível para uso.
NASCompares tem uma lista de unidades e se elas usam tecnologia CMR ou SMR normal em Lista de discos rígidos WD CMR e SMR (HDD) . Você pode filtrar a lista por marca, modelo e assim por diante para encontrar sua unidade específica.
Eu vi algumas unidades que literalmente parecem ter morrido durante a gravação. Eles aceitam vários GB de dados e, em seguida, as gravações caem para zero por algum período de tempo enquanto a unidade reorganiza os dados para limpar a zona CMR. Depois que a unidade libera o "cache", ela continua gravando, mas por um período de tempo medido em minutos, a unidade fica praticamente inutilizável.
Contanto que você esteja ciente de que possui uma dessas unidades, não há problema, mas se você não souber, pode parecer que a unidade está com defeito ou fazendo algo muito estranho.
O comportamento padrão do Linux é armazenar em cache na RAM. Como resultado, o Read pode terminar muito antes do Write . Dependendo do tamanho e velocidade dos dispositivos essa diferença pode ser bem grande, principalmente com muita RAM disponível.
Não sei por que " Concluído " é anunciado com base na leitura, mas você precisa ter cuidado para permitir que a gravação seja concluída antes de remover a unidade.
Outra possibilidade está relacionada a tamanhos de bloco relativos . Se o seu dispositivo de leitura tiver um zilhão de arquivos minúsculos com um tamanho de bloco pequeno e seu dispositivo de gravação tiver um tamanho de bloco grande, você poderá sobrecarregar completamente o dispositivo de gravação gravando arquivos minúsculos que ocupam blocos grandes.
Gostaria de saber se há aprimoramentos/sinalizadores do sistema de arquivos que poderiam ajudar a mitigar os problemas aqui? O Linux ext4 é bastante conhecido por ser muito menos sujeito à fragmentação do que o NTFS, porque também reorganiza os blocos em tempo real ao gravar dados de arquivo e separa as gravações de metadados (no diário) das gravações de bloco de arquivo. Mas isso pode piorar as coisas com o SMR, especialmente no layout padrão, onde cada gravação envolve gravações de diário e atualizações de blocos do sistema de arquivos, em áreas completamente separadas do disco.
O desenvolvedor do kernel Ted Ts'o e outros analisaram esse caminho em 2017 e criaram uma variação "ext4-lazy" na implementação do sistema de arquivos padrão que evitou desencadear muitos dos piores comportamentos do SMR. Infelizmente, parece que esses patches nunca chegaram ao kernel e, como já se passaram quatro anos, não tenho muita esperança de que o façam.
Mas, ainda assim, o trabalho deles apontou para alguns ajustes na implementação atual do ext4 que podem beneficiar você:
tune2fs -J size=40000 /dev/foo. A pesquisa de Ts'o mostrou que usar um diário grande como cache de gravação foi uma melhoria significativa.tune2fs -o journal_data /dev/foo, para que "todos os dados (não apenas os metadados) sejam confirmados no diário antes de serem gravados no sistema de arquivos principal".mke2fs -O journal_dev /dev/bar. "Observe que [/dev/bar] deve ser formatado com o mesmo tamanho de bloco dos sistemas de arquivos que o usarão." então você definiria esse dispositivo como o diário para/dev/foousartune2fs -J device=/dev/bar /dev/foo.Se você for fazer o último, esqueça a primeira sugestão, pois o tamanho do diário será apenas o tamanho de
/dev/bar. (Embora eu suspeite que ainda não usará mais do que 40 GB, então, pelo lado bom, você não precisa de um grande disco de diário!) Desnecessário dizer que provavelmente é mais seguro tentar fazer qualquer um desses ajustes somente após primeiro desmontar o sistema de arquivos em questão e, embora eu tenha certeza de quetune2fshesitaria se solicitado a fazer algo destrutivo, para segurança máxima, é uma boa ideia fazer um backup ou, pelo menos, experimentar primeiro um sistema de arquivos descartável.