Como solucionar problemas con ST8000AS0002-1NA17Z (8 Tb) en Linux (rsync, dd, cp...)

Si nos hemos comprado el flamante disco duro de Seagate y probado en nuestro Ubuntu (o cualquier otra distribución), veremos que lo detecta sin problemas y que parece funcionar bien. Pero como los que compramos este tipo de discos es porque probablemente lo queremos para soluciones de respaldo (backup), sabremos que al hacer rsync, dd, cp o cualquier otra instrucción contra este disco, hace que el kernel de un error y se nos queda en modo lectura (read-only). Un ejemplo de lo que podemos ver en el syslog es este:

Feb 10 08:57:59 eithel-server kernel: [149638.596415] ------------[ cut here ]------------
Feb 10 08:57:59 eithel-server kernel: [149638.596441] WARNING: CPU: 3 PID: 8153 at /build/linux-lts-vivid-whAhIw/linux-lts-vivid-3.19.0/fs/btrfs/super.c:260 __btrfs_abort_transaction+0x54/0x130 [btrfs]()
Feb 10 08:57:59 eithel-server kernel: [149638.596443] BTRFS: Transaction aborted (error -5)
Feb 10 08:57:59 eithel-server kernel: [149638.596444] Modules linked in: nouveau mxm_wmi wmi video ttm drm_kms_helper drm snd_hda_codec_hdmi i2c_algo_bit intel_powerclamp snd_hda_codec_via snd_hda_codec_generic snd_hda_intel coretemp snd_hda_controller snd_hda_codec kvm_intel snd_hwdep kvm snd_pcm snd_timer snd soundcore serio_raw shpchp 8250_fintek lpc_ich asus_atk0110 mac_hid lp parport btrfs xor raid6_pq pata_acpi psmouse r8169 ahci libahci mii pata_via
Feb 10 08:57:59 eithel-server kernel: [149638.596462] CPU: 3 PID: 8153 Comm: kworker/u32:29 Tainted: G          I    3.19.0-25-generic #26~14.04.1-Ubuntu
Feb 10 08:57:59 eithel-server kernel: [149638.596463] Hardware name: System manufacturer System Product Name/P7P55 LX, BIOS 1102    01/03/2011
Feb 10 08:57:59 eithel-server kernel: [149638.596475] Workqueue: btrfs-extent-refs btrfs_extent_refs_helper [btrfs]
Feb 10 08:57:59 eithel-server kernel: [149638.596476]  ffffffffc041ef40 ffff880002687c28 ffffffff817aed00 0000000000000000
Feb 10 08:57:59 eithel-server kernel: [149638.596478]  ffff880002687c78 ffff880002687c68 ffffffff81074d8a 0000000102687c68
Feb 10 08:57:59 eithel-server kernel: [149638.596479]  ffff880118f071e0 ffff8800d3c7b000 00000000fffffffb ffffffffc041b0b0
Feb 10 08:57:59 eithel-server kernel: [149638.596481] Call Trace:
Feb 10 08:57:59 eithel-server kernel: [149638.596489]  [] dump_stack+0x45/0x57
Feb 10 08:57:59 eithel-server kernel: [149638.596493]  [] warn_slowpath_common+0x8a/0xc0
Feb 10 08:57:59 eithel-server kernel: [149638.596495]  [] warn_slowpath_fmt+0x46/0x50
Feb 10 08:57:59 eithel-server kernel: [149638.596501]  [] __btrfs_abort_transaction+0x54/0x130 [btrfs]
Feb 10 08:57:59 eithel-server kernel: [149638.596508]  [] btrfs_run_delayed_refs.part.66+0x12c/0x2a0 [btrfs]
Feb 10 08:57:59 eithel-server kernel: [149638.596516]  [] delayed_ref_async_start+0x88/0xa0 [btrfs]
Feb 10 08:57:59 eithel-server kernel: [149638.596527]  [] normal_work_helper+0xc2/0x2b0 [btrfs]
Feb 10 08:57:59 eithel-server kernel: [149638.596537]  [] btrfs_extent_refs_helper+0x12/0x20 [btrfs]
Feb 10 08:57:59 eithel-server kernel: [149638.596540]  [] process_one_work+0x14f/0x400
Feb 10 08:57:59 eithel-server kernel: [149638.596541]  [] worker_thread+0x118/0x510
Feb 10 08:57:59 eithel-server kernel: [149638.596543]  [] ? rescuer_thread+0x3d0/0x3d0
Feb 10 08:57:59 eithel-server kernel: [149638.596546]  [] kthread+0xd2/0xf0
Feb 10 08:57:59 eithel-server kernel: [149638.596548]  [] ? kthread_create_on_node+0x1c0/0x1c0
Feb 10 08:57:59 eithel-server kernel: [149638.596552]  [] ret_from_fork+0x58/0x90
Feb 10 08:57:59 eithel-server kernel: [149638.596553]  [] ? kthread_create_on_node+0x1c0/0x1c0
Feb 10 08:57:59 eithel-server kernel: [149638.596555] ---[ end trace ce5daf4bc8891b5b ]---
Feb 10 08:57:59 eithel-server kernel: [149638.596557] BTRFS: error (device sde1) in btrfs_run_delayed_refs:2792: errno=-5 IO failure
Feb 10 08:57:59 eithel-server kernel: [149638.596680] BTRFS info (device sde1): forced readonly

En el ejemplo anterior vemos que he usado el sistema de archivos btrfs. Pues no os preocupeis, no es por el sistema de archivos. El mismo problema te dara cambiando las opciones de montaje del btrfs o probándolo con cualquier otro sistema de archivos ( ext2/3/4, jfs, zfs, xfs, ... ) a excepción de NTFS. Con NTFS no pasa. Podeis hacer vuestras pruebas y con casi total seguridad llegaréis a la misma conclusión.

Y.. ¿ahora que? Bueno, la clave esta en saber que el problema es de nuestro kernel. Así que actualizamos nuestro ubuntu 15.10 (wily) desde el repositorio para ver si lo arregla y seguimos sin arreglarlo:

Linux MiMaquina 4.2.0-27-generic #32-Ubuntu SMP Fri Jan 22 04:49:08 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Entonces ya podemos empezar a caer en la desesperación. Pero aun no esta todo perdido. Podemos mirar de ir más allá del kernel oficial de nuestro repositorio y bajarnos una actualización mayor. Para ello seguiremos el artículo ya publicado:

• Actualizar kernel de Ubuntu a 4.4.* desde paquetes

Una vez actualizado el sistema veremos que ya todos nuestros problemas han acabado y que el disco no se pone en sólo lectura al hacer rsync, dd o cp de gran cantidad de archivos.

Si queremos estar seguros de nuestro modelo de disco duro podemos utilizar los parámetros de hdparm según el artículo publicado anteriormente:

• hdparm: Parametrizar tu disco duro