Hace un par de semanas, se descubrió un error en la versión del kernel de Linux 5.1 que provocó la pérdida de datos en el SSD. Recientemente, los desarrolladores
lanzaron el parche parche Linux 5.1.5, que llenó un "vacío".
Discutimos cuál fue la razón.
/ Unsplash / Glen CarrieQue bicho
A principios de año, los desarrolladores hicieron una serie de cambios en el núcleo Linux 5.1. Después de eso, en los sistemas con SSD de Samsung que utilizan el cifrado dm-crypt / LUKS con el mapeador de dispositivos / LVM,
comenzó a aparecer un
error que condujo a la pérdida de datos. Pero el problema
se conoció solo a mediados de mayo, en ese momento comenzaron a
discutirlo activamente
en foros temáticos .
Se conocen al menos dos personas que conocen el error
: el miembro de la lista de correo de
LKML Michael Laß, que
informó por primera
vez el problema , y el
usuario de ArchLinux.
Michael
ejecutó el comando fstrim, que le dice a la unidad qué bloques de datos ya no se usan para el volumen btrfs montado. Después de recibir los siguientes mensajes del sistema:
attempt to access beyond end of device sda1: rw=16387, want=252755893, limit=250067632 BTRFS warning (device dm-5): failed to trim 1 device(s), last error -5 BTRFS warning (device dm-5): csum failed root 257 ino 16634085 off 21504884736 csum 0xd47cc2a2 expected csum 0xcebd791b mirror 1
Después de eso, descubrió que el volumen btrfs estaba dañado y los volúmenes lógicos restantes en el dispositivo físico fueron destruidos.
En el caso del usuario de ArchLinux, el problema afectó la protección criptográfica de LUKS. Después de reiniciar el sistema operativo y ejecutar fstrim, los encabezados LUKS (que se utilizan para buscar volúmenes) resultaron ilegibles, lo que no permitió descifrar datos cifrados.
Cual es la razon
El problema era el subsistema de
mapeador de dispositivos (DM), cuya tarea era crear dispositivos de bloques virtuales. Solo se usa para implementar el administrador de volumen lógico LVM, RAID de software y el sistema de cifrado de disco dm-crypt.
“El equipo de fstrim marcó demasiados bloques a la vez sin tener en cuenta el límite max_io_len_target_boundary. Como resultado, esos segmentos de memoria que todavía están en uso se liberan ”, comenta Sergey Belkin, jefe del departamento de desarrollo 1cloud.ru . "Dado que el error estaba relacionado con el mapeador de dispositivos, en teoría, la pérdida de datos podría ocurrir en cualquier sistema de archivos".
Parche
Los desarrolladores del kernel lanzaron un parche para el error a fines de mayo. Solo se
cambiaron cuatro líneas en el archivo drivers / md / dm.c. Los cambios correspondientes también se realizaron en el próximo núcleo Linux 5.2 (las líneas agregadas y eliminadas están marcadas con “+” y “-”, respectivamente):
@@ -1467,7 +1467,7 @@ static unsigned get_num_write_zeroes_bios(struct dm_target *ti) static int __send_changing_extent_only(struct clone_info *ci, struct dm_target *ti, unsigned num_bios) { - unsigned len = ci->sector_count; + unsigned len; @@ -1478,6 +1478,8 @@ static int __send_changing_extent_only(struct clone_info *ci, struct dm_target * if (!num_bios) return -EOPNOTSUPP; + len = min((sector_t)ci->sector_count, max_io_len_target_boundary(ci->sector, ti)); + __send_duplicate_bios(ci, ti, num_bios, &len); ci->sector += len;
El parche ya ha sido aplicado por los desarrolladores de distribución de
ArchLinux / Manjaro y
Fedora . La distribución de Ubuntu
no afectó el error, ya que no se tradujo a la versión del kernel de Linux 5.1.
/ Flickr / Andy Melton / CC BY-SAPuede eliminar la situación de pérdida de datos sin instalar el parche. Es suficiente deshabilitar el servicio fstrim.service / timer usando los comandos:
systemctl disable fstrim.timer systemctl stop fstrim.timer
Otra opción es cambiar el nombre del ejecutable fstrim o eliminar el indicador de descarte al montar fstab. También puede desactivar allow-descartes en LUKS a través de dmsetup. Sin embargo, todos estos métodos
no son
más que temporales y no resuelven la esencia del problema.
No la primera vez
Esta no es la primera vez que una confirmación en el kernel de Linux conduce a situaciones de corrupción de memoria. Una historia similar
sucedió en la versión 4.19 de Linux: entonces los culpables eran los programadores de E / S BLK-MQ. El problema se manifestó al compilar el kernel con la opción CONFIG_SCSI_MQ_DEFAULT = y, establecida de manera predeterminada. En algunos casos, los datos del volumen
estaban dañados.
sed: error while loading shared libraries: /lib/x86_64-linux-gnu/libattr.so.1: unexpected PLT reloc type 0x00000107 sed: error while loading shared libraries: /lib/x86_64-linux-gnu/libattr.so.1: unexpected PLT reloc type 0x00000107
Muy a menudo, el problema se manifestó con EXT4, pero en teoría podría afectar a otros sistemas de archivos.
Luego, uno de los encargados del kernel
preparó una pequeña solución que resolvió el problema. Sin embargo, el mismo error se descubrió más tarde en la compilación Linux 4.20. Finalmente fue posible
deshacerse de él a fines de diciembre de 2018 con una nueva actualización global.
Nuestros recursos y fuentes adicionales:
Copia de seguridad de archivos: cómo estar a salvo de la pérdida de datos
Minimización de riesgos: cómo no perder sus datos
Copia de seguridad y recuperación: transmisión y deduplicación inteligente, instantáneas y almacenamiento secundario
Cómo ahorrar dinero usando la interfaz de programación de aplicaciones
DevOps en un servicio en la nube usando 1cloud.ru como ejemplo
1cloud Cloud Architecture Evolution
Cómo trabajamos: el resumen de 1cloud
Posibles ataques a HTTPS y formas de protección contra ellos.