Tema: btrfs
-
Comprobación y reparación de sistemas de archivos: fsck, xfs_repair y btrfs check en un sistema de archivos desmontado
ext4, XFS y Btrfs incluyen cada uno su propio verificador, con reglas de seguridad distintas: e2fsck y xfs_repair deben ejecutarse sobre un sistema de archivos desmontado (xfs_repair tiene un modo de simulación, -n), mientras que btrfs check es de solo lectura por defecto y desaconseja con firmeza --repair. Los códigos de salida y el resultado de la simulación, no la intuición, determinan si hace falta reparar.
-
Instantáneas de Btrfs y reversión con snapper en SUSE: pares pre/post, arranque desde GRUB y limpieza
En una raíz Btrfs, el snapper de SUSE toma un par de instantáneas pre/post en cada cambio de zypper o YaST, las lista con snapper list, y puede revertir todo el sistema o arrancar directamente en una instantánea antigua desde el menú de GRUB. Las instantáneas antiguas se limpian de forma automática, pero es la política de limpieza —y no solo el tamaño del disco— la que decide cuánto historial se conserva.
-
Actualizaciones transaccionales en SUSE Linux Micro, openSUSE MicroOS y Leap Micro: raíz de solo lectura y activación mediante reinicio
En los productos de SUSE con raíz inmutable, transactional-update instala los cambios en una nueva instantánea de un sistema de archivos de solo lectura en lugar de modificar el sistema en ejecución. Nada surte efecto hasta que un reinicio activa esa instantánea, y una actualización defectuosa se deshace con rollback, no con una reversión de paquetes. En SLES convencional el mecanismo existe, pero se documenta como vista previa tecnológica (technology preview) para una raíz de solo lectura, no como configuración predeterminada.
Legible por máquina: JSON