Informações básicas de hardware:
O disco rígido em questão é um Seagate BarraCuda 4TB (número do modelo: ST4000DM004). Para obter mais detalhes, consulte a saída de hdparm -Ientre os apêndices no final.
Descrição do problema e testes:
O problema, na superfície, parece ser exatamente como o cache dos dados a serem gravados no disco enquanto a velocidade de gravação é mais lenta que isso. No entanto, as coisas não parecem ser tão simples neste caso.
Copiando arquivos (em um sistema de arquivos NTFS):
Ao gravar uma quantidade razoavelmente grande de dados, o desempenho da unidade cairá repentina e drasticamente. Novamente, geralmente isso seria tão simples quanto armazenar arquivos em cache na RAM e depois o disco funcionar por um tempo. Aqui, no entanto, ao monitorar o /proc/meminfoarquivo (no Ubuntu), o comportamento observado não parece suportar isso. Mesmo depois de gravar os dados (arquivos grandes ou vários menores) e chamar sync, a quantidade de memória “suja” continuará a diminuir por um tempo, depois chegará a uma parada quase completa. Vai diminuir muitolentamente, até que às vezes acelere. Isso pode se repetir, dependendo da quantidade de dados restantes. A leitura do dispositivo também é extremamente lenta quando a velocidade de escrita diminui e permanecerá assim por um tempo, mesmo após synca conclusão, se o fizer em “modo lento”.
Esses testes iniciais foram realizados tanto no Ubuntu 21.10 quanto no Windows 10, com comportamento semelhante.
Observação adicional para o Windows:
Quando o disco ficou lento após concluir a operação de cópia e tentei ler arquivos do disco (por exemplo, reproduzir um vídeo, que continuava atrasado), o Monitor de Recursos e o Gerenciador de Tarefas mostraram uma alta porcentagem de uso do disco no dispositivo (100% ou próximo disso) enquanto a velocidade real mostrada era <1 MB/s. (O sistema operacional também conseguiu congelar completamente em um ponto, mas isso pode ou não estar estritamente relacionado.)
Benchmarks de disco:
Para ver se isso se deve ao sistema de arquivos ou ao próprio hardware, realizei benchmarks no dispositivo usando o gnome-disksutilitário. O resultado de um desses benchmarks que mostrarei aqui exemplifica o que descrevi acima, as velocidades de leitura e gravação caindo drasticamente para quase inexistência após um ponto, recuperando-se posteriormente (azul e vermelho são respectivamente velocidades de leitura e gravação em cada amostra individual tomada em locais indo de fora para dentro do disco, 1000 no total; os pontos e linhas verdes correspondem ao benchmark de tempo de acesso que é separado dos demais):
Observe que, pelo meu entendimento, a ferramenta de benchmarking elimina fatores como cache de gravação. Além disso, /proc/meminfomostrou pouco ou nenhum dado esperando para ser gravado sendo mantido em cache durante os períodos lentos em qualquer caso; o conteúdo completo do mesmo pode ser visto entre os apêndices.
Com as gravações desabilitadas no benchmark, esse fenômeno não se apresenta, embora pareça haver uma diminuição repentina e anômala na velocidade nas seções internas do disco:
(A localização da diminuição não depende do tempo gasto, mas sim da localização física no disco, conforme indicado por outros benchmarks com um número de amostra diferente, onde o corte ocorre no mesmo local.)
Benchmarks equivalentes em outros discos rígidos presumivelmente saudáveis no sistema produzem os resultados esperados e regulares como este:
Conclusão / Pergunta:
A partir disso, deduzo que o problema provavelmente é causado por alguma falha de hardware ou firmware, mas pode haver várias coisas que eu ignorei.
Quais podem ser as causas prováveis do fenômeno apresentado? Quais próximos passos devo tomar para diagnosticar o problema ainda mais? Qualquer ajuda é muito apreciada.
Apêndices:
Informações detalhadas de hardware (como saída de hdparm -I):
/dev/sdb:
ATA device, with non-removable media
Model Number: ST4000DM004-2CV104
Serial Number: ZFN3J8RH
Firmware Revision: 0001
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Used: unknown (minor revision code 0x006d)
Supported: 10 9 8 7 6 5
Likely used: 10
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 7814037168
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 3815447 MBytes
device size with M = 1000*1000: 4000787 MBytes (4000 GB)
cache/buffer size = unknown
Form Factor: 3.5 inch
Nominal Media Rotation Rate: 5425
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Recommended acoustic management value: 208, current value: 208
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
Power-Up In Standby feature set
* SET_FEATURES required to spinup after power up
SET_MAX security extension
* 48-bit Address feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* WRITE_{DMA|MULTIPLE}_FUA_EXT
* 64-bit World wide name
Write-Read-Verify feature set
* WRITE_UNCORRECTABLE_EXT command
* {READ,WRITE}_DMA_EXT_GPL commands
* Segmented DOWNLOAD_MICROCODE
* unknown 119[6]
* unknown 119[7]
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Gen3 signaling speed (6.0Gb/s)
* Native Command Queueing (NCQ)
* Host-initiated interface power management
* Phy event counters
* READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
* DMA Setup Auto-Activate optimization
Device-initiated interface power management
* Software settings preservation
unknown 78[7]
* SMART Command Transport (SCT) feature set
* SCT Write Same (AC2)
* SCT Data Tables (AC5)
unknown 206[7]
unknown 206[12] (vendor specific)
unknown 206[13] (vendor specific)
* DOWNLOAD MICROCODE DMA command
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
supported: enhanced erase
490min for SECURITY ERASE UNIT. 490min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000c500c6a79fae
NAA : 5
IEEE OUI : 000c50
Unique ID : 0c6a79fae
Checksum: correct
/proc/meminfodurante o primeiro benchmark, no momento em que a velocidade de leitura/gravação era lenta:
MemTotal: 16323712 kB
MemFree: 9894056 kB
MemAvailable: 12815716 kB
Buffers: 138380 kB
Cached: 3038420 kB
SwapCached: 0 kB
Active: 1533040 kB
Inactive: 4396560 kB
Active(anon): 2960 kB
Inactive(anon): 2817480 kB
Active(file): 1530080 kB
Inactive(file): 1579080 kB
Unevictable: 32 kB
Mlocked: 32 kB
SwapTotal: 17577980 kB
SwapFree: 17577980 kB
Dirty: 176 kB
Writeback: 0 kB
AnonPages: 2752844 kB
Mapped: 694816 kB
Shmem: 73200 kB
KReclaimable: 137092 kB
Slab: 260112 kB
SReclaimable: 137092 kB
SUnreclaim: 123020 kB
KernelStack: 13872 kB
PageTables: 33292 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 25739836 kB
Committed_AS: 9749696 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 76616 kB
VmallocChunk: 0 kB
Percpu: 8128 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 512904 kB
DirectMap2M: 7813120 kB
DirectMap1G: 8388608 kB
O Seagate ST4000DM004 usa SMR para gravar dados na superfície do disco. Isso significa que, para gravar um único byte, pode ser necessário reescrever vários gigabytes .
Em "padrões de uso normal" (como designados pelos fornecedores de HDD, não pelos usuários!) isso não cria muito problema - os dados são gravados em um cache CMR na borda externa do disco. Mais tarde, quando o uso do disco cair, o firmware moverá a data para seu local final em uma banda SMR.
Ao gravar grandes quantidades de dados por vez, esse cache CMR é esgotado e o processo de E/S para bandas SMR precisa assumir o controle - isso é mais lento em ordens de magnitude.
Nota: Este não é um cache de RAM - é uma pequena parte da superfície do disco, que é escrita em CMR (ou seja, sem faixas sobrepostas) para tornar o horror SMR menos visível para os usuários.
Os discos rígidos gravam dados em setores nas trilhas, no entanto, há um limite de quão próximas as trilhas podem ser colocadas sem interferir umas nas outras.
Os fornecedores de discos rígidos perceberam que o problema de faixas adjacentes interferindo umas com as outras poderia ser mitigado se desistissem do modelo tradicional de acesso aleatório de gravação e gravassem grandes áreas de dados sequencialmente. Cada faixa escrita se sobrepõe ligeiramente à última. Isso significa mais dados por prato, o que significa maior capacidade e/ou menor custo. Isto é conhecido como "Shingled Magnetic Recording" ( SMR ), por analogia com a forma como as telhas se sobrepõem.
Claro, que um disco rígido que exigisse grandes mudanças no sistema operacional não venderia muito bem. Então, eles adicionaram firmware de tradução e uma área de cache CMR , para que a unidade SMR parecesse uma unidade normal para o sistema operacional. Não é muito diferente do que os fornecedores de SSD já fazem.
A diferença é que o flash é rápido, portanto, mesmo com a camada de tradução, os SSDs ainda eram muito mais rápidos que os HDDs. Os HDDs SMR, por outro lado, têm um desempenho que cai de um penhasco quando a área de cache CMR se esgota e a unidade deve bloquear novas operações de gravação no processo lento de reescrever shingles.
Infelizmente, todos os três fornecedores de HDD restantes decidiram que a maneira de lançar essa tecnologia seria inserindo-a na linha de produtos sem contar às pessoas sobre isso. Então, em vez de poder fazer uma escolha consciente de aceitar ou não um precipício de desempenho em troca de um custo ligeiramente menor por unidade de armazenamento, as pessoas receberam essas unidades sem saber. Sob pressão da mídia, eles finalmente divulgaram as informações sobre quais modelos de unidade eram SMR, mas ainda não é óbvio para os clientes.
Como foram os três principais fornecedores de HDD que fizeram isso, você não pode simplesmente boicotar os culpados, então parece que a única opção é verificar cuidadosamente cada disco rígido que você comprar a partir de agora.
Curiosamente, apesar da motivação original por trás da capacidade do SMR, parece que as maiores unidades ainda eram CMR, com o SMR sendo visto principalmente em unidades nos terabytes de um dígito baixo.