Sujet : btrfs
-
Vérifier et réparer un système de fichiers démonté : fsck, xfs_repair et btrfs check
ext4, XFS et Btrfs fournissent chacun leur propre outil de vérification, avec des règles de sécurité différentes : e2fsck et xfs_repair doivent s'exécuter sur un système de fichiers démonté (xfs_repair dispose d'un mode d'essai -n), tandis que btrfs check est en lecture seule par défaut et déconseille fortement --repair. Ce sont les codes de retour et la sortie du mode d'essai, non l'intuition, qui déterminent si une réparation est nécessaire.
-
Snapshots Btrfs et retour arrière avec snapper sous SUSE : paires pre/post, démarrage depuis GRUB et nettoyage
Sur une racine Btrfs, snapper de SUSE crée une paire de snapshots pre/post autour de chaque modification faite avec zypper ou YaST, les affiche avec snapper list et permet soit de restaurer tout le système, soit de démarrer directement un ancien snapshot depuis le menu GRUB. Les anciens snapshots sont nettoyés automatiquement, mais c'est la politique de nettoyage, et pas seulement la taille du disque, qui détermine l'historique conservé.
-
Mises à jour transactionnelles sur SUSE Linux Micro, openSUSE MicroOS et Leap Micro : racine en lecture seule et activation au redémarrage
Sur les produits SUSE à racine immuable, transactional-update installe les modifications dans un nouvel instantané d'un système de fichiers en lecture seule au lieu de toucher au système en cours d'exécution ; rien ne prend effet avant un redémarrage qui active cet instantané, et une mise à jour défectueuse s'annule par rollback plutôt que par rétrogradation de paquets. Sur SLES classique, le même mécanisme existe mais il est documenté comme préversion technologique pour une racine en lecture seule, et non comme configuration par défaut.
Lisible par machine : JSON