Información básica de hardware:
El disco duro en cuestión es un Seagate BarraCuda de 4 TB (número de modelo: ST4000DM004). Para obtener más detalles, consulte el resultado de hdparm -Iuno de los apéndices al final.
Descripción del problema y pruebas:
El problema, en la superficie, parece ser simplemente como el almacenamiento en caché de los datos que se van a escribir en el disco mientras la velocidad de escritura es más lenta. Sin embargo, las cosas no parecen tan sencillas en este caso.
Copiar archivos (en un sistema de archivos NTFS):
Al escribir una cantidad razonablemente grande de datos, el rendimiento de la unidad disminuirá repentina y bruscamente. Nuevamente, generalmente esto sería tan simple como almacenar en caché los archivos en la RAM y luego el disco funcionar durante un tiempo. Aquí, sin embargo, al monitorear el /proc/meminfoarchivo (en Ubuntu), el comportamiento observado no parece respaldar esto. InclusodespuésAl escribir los datos (ya sean archivos grandes o varios más pequeños) y llamar a sync, la cantidad de memoria "sucia" seguirá disminuyendo durante un tiempo y luego se detendrá casi por completo. Seguirá disminuyendomuylentamente, hasta que a veces eventualmente se acelera. Esto puede repetirse, dependiendo de la cantidad de datos que queden. La lectura del dispositivo también es extremadamente lenta cuando la velocidad de escritura disminuye, y permanecerá así durante un tiempo incluso después de synccompletarse si lo hace en "modo lento".
Estas pruebas iniciales se realizaron tanto desde Ubuntu 21.10 como desde Windows 10, con un comportamiento similar.
Observación adicional para Windows:
Cuando el disco permaneció lento después de completar la operación de copia e intenté leer archivos del disco (por ejemplo, reproducir un video, que seguía retrasado), el Monitor de recursos y el Administrador de tareas mostraron un alto porcentaje de uso del disco en el dispositivo (100% o cerca de él) mientras que la velocidad real mostrada era <1 MB/s. (El sistema operativo también logró congelarse por completo en un momento, pero eso puede estar estrictamente relacionado o no).
Puntos de referencia de disco:
Para ver si esto se debe al sistema de archivos o al hardware en sí, realicé pruebas comparativas en el dispositivo usando la gnome-disksutilidad. El resultado de uno de esos puntos de referencia que mostraré aquí ejemplifica lo que describí anteriormente: las velocidades de lectura y escritura caen bruscamente hasta casi la inexistencia después de un punto, y luego se recuperan más tarde (el azul y el rojo son velocidades de lectura y escritura respectivamente en cada muestra individual tomada en ubicaciones que van desde el exterior del disco hacia el interior, 1000 en total; los puntos y líneas verdes corresponden al punto de referencia de tiempo de acceso que está separado de los demás):
Tenga en cuenta que, según tengo entendido, la herramienta de evaluación comparativa elimina factores como el almacenamiento en caché de escritura. Además, /proc/meminfoen cualquier caso, mostró que había pocos o ningún dato en espera de ser escrito que se mantuviera en caché durante los períodos lentos; el contenido completo del mismo se puede ver entre los anexos.
Con las escrituras deshabilitadas en el punto de referencia, no se presenta tal fenómeno, aunque parece haber una disminución repentina y anómala de la velocidad en las secciones internas del disco:
(La ubicación de la disminución esnodepende del tiempo invertido, sino más bien de la ubicación física en el disco, como lo indican otros puntos de referencia con un número de muestra diferente donde el corte ocurre en el mismo lugar).
Los puntos de referencia equivalentes en otros discos duros del sistema, presumiblemente en buen estado, arrojan los resultados esperados y regulares como este:
Conclusión / Pregunta:
De esto deduzco que el problema probablemente se debe a alguna falla de hardware o firmware, pero es posible que haya pasado por alto varias cosas.
¿Cuáles podrían ser las causas probables del fenómeno presentado? ¿Qué próximos pasos debo seguir para diagnosticar más el problema? Cualquier ayuda es muy apreciada.
Apéndices:
Información detallada del hardware (como resultado 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 el primer punto de referencia, en el momento en que la velocidad de lectura/escritura 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
Respuesta1
El Seagate ST4000DM004 utilizaSMRpara escribir datos en la superficie del disco. Esto significa que para escribir un solo byte, es posible que tenga que reescribir variosgigabytes.
En los "patrones de uso normales" (como los designan los proveedores de HDD, no los usuarios), esto no crea un gran problema: los datos se escriben en unRMCcaché en el borde exterior del disco. Más tarde, cuando el uso del disco disminuya, el firmware moverá la fecha a su lugar final en una banda SMR.
Cuando se escriben grandes cantidades de datos a la vez, esta caché CMR se agota y el proceso de E/S a bandas SMR tiene que hacerse cargo; esto es más lento en órdenes de magnitud.
Nota bene: Esto no es un caché de RAM - es una pequeña parte de la superficie del disco, que está escrita en CMR (es decir, sin pistas superpuestas) para hacer que el horror SMR sea menos visible para los usuarios.
Respuesta2
Los discos duros escriben datos en sectores de las pistas; sin embargo, existe un límite en cuanto a qué tan cerca se pueden colocar las pistas sin interferir entre sí.
Los proveedores de discos duros se dieron cuenta de que el problema de las pistas adyacentes que interferían entre sí se podía mitigar si abandonaban el modelo tradicional de acceso de escritura aleatoria y escribían grandes áreas de datos de forma secuencial. Cada pista escrita se superpondría ligeramente con la anterior. Eso significa más datos por plato, lo que significa mayor capacidad y/o menor costo. Esto se conoce como "grabación magnética con tejas" (SMR), por analogía con la forma en que se superponen las tejas del techo.
Por supuesto, un disco duro que requiriera cambios importantes en el sistema operativo no se vendería muy bien. Entonces agregaron firmware de traducción y unRMCárea de caché, para que la unidad SMR parezca una unidad normal para el sistema operativo. No es muy diferente de lo que ya hacen los proveedores de SSD.
Sin embargo, la diferencia es que el flash es rápido, por lo que incluso con la capa de traducción, los SSD seguían siendo mucho más rápidos que los HDD. Los discos duros SMR, por otro lado, tienen un rendimiento que cae por un precipicio cuando el área de caché CMR se agota y la unidad debe bloquear nuevas operaciones de escritura en el lento proceso de reescritura de tejas.
Desafortunadamente, los tres proveedores de HDD restantes decidieron que la forma en que lanzarían esta tecnología sería introduciéndola en la línea de productos sin decírselo a la gente. Entonces, en lugar de poder tomar una decisión consciente entre aceptar o no un límite de rendimiento a cambio de un costo ligeramente menor por unidad de almacenamiento, las personas recibieron estas unidades sin saberlo. Bajo la presión de los medios, finalmente publicaron información sobre qué modelos de unidades eran SMR, pero aún no es obvio para los clientes.
Dado que fueron los tres principales proveedores de HDD quienes hicieron esto, no se puede simplemente boicotear a los culpables, por lo que parece que la única opción es revisar cuidadosamente cada disco duro que compre a partir de ahora.
Curiosamente, a pesar de que la motivación original detrás de SMR era la capacidad, parece que las unidades más grandes a menudo seguían siendo CMR y SMR se ve principalmente en unidades de terabytes de un solo dígito.