Si la copie d’un fichier a été interrompue, on peut la reprendre avec rsync --append (qui va bêtement reprendre si le fichier de destination est plus petit que le fichier source) ou rsync --append-verify (qui va vérifier que les données pré-existantes sont bien les mêmes sur la source et la destination).
backup sans accès root
Ceci peut se faire grâce à l’option --fake-super.
L’ensemble des données copiées dans la destination appartiendront à l’utilisateur qui lance rsync, mais les metadonnées (user, group, perms, symlink, etc…) seront stockés dans des attributs étendus.
# detegtion auto de la partition systeme
guestmount --add disk.vhdx --inspector --ro /mnt/
# ou choix manuel de la partition
guestmount --add disk.vhdx -m /dev/sda1 --ro /mnt/
Il faut que l’utilisateur ait des droits d’écriture sur le point de montage.
Si on lance la commande avec sudo, l’utilisateur simple ne pourra pas parcourir le contenu.
L’option --inspector va analyser le disque, et sélectionner automatiquement ce qui ressemble à une partition système.
Si plusieurs partitions, on peut la sélectionner avec l’option -m device. L’identifiant de disque (sda) ne correspond PAS au disque de l’hôte ; le disque virtuel est considéré comme sda (à voir si différent si plusieurs disques montés ? )
Si la partition n’est pas montable (mauvais numéro ou FS illisible), un message d’erreur va lister les partitions valides et leur FS.
On peut aussi lister les partitions avec virt-filesystems -a disk.vhdx
Un bloc-notes se compose d’une plusieurs sections, qui contiennent elles-même 1 ou plusieurs pages ; ces pages contiennent elles-même un ou plusieurs post-it (appellés je suppose notes)
Local
En local, un bloc-notes prend la forme d’un dossier. Le nom du dossier est le nom du bloc-notes.
Dedans, il y a un fichier “Ouvrir le bloc-notes” qui doit être un genre de table des matières (fichier .onetoc2). On peut le renommer sans problème, et s’il est absent, il sera recréé automatiquement.
Et un fichier pour chaque section (fichier .one) , que l’on peut aussi ouvrir directement.
À l’ouverture du bloc, il scanne automatiquement les fichiers .one et ajoute/supprime les sections à la volée.
On peut déplacer les sections sans problème d’un bloc-notes vers un autre (ou un dossier vide qui sera donc considéré comme un bloc-notes), OneNote detectera les modifications.
Cloud
Si un dossier bloc-notes est copié sur OneDrive, alors il est automatiquement converti en lien vers la page web OneNote
Un (sous-)volume est une arborescence de fichiers autonome.
Chaque volume a son propre espace d’inodes. Il peut donc y en avoir des inodes identiques au sein de différents volume.
L’inode d’un volume est toujours 256.
La racine du FS est elle-même un sous-volume, appelé top-level, avec un ID de 5. Ce sous-volume ne peut pas être supprimé/remplacé.
Un volume peut être monté indépendemment du reste du FS btrfs auquel il appartient, via l’argument subvol=/@mysubvolume ou subvolid=257
Il est sinon possible de parcourir un sous-volume comme un simple dossier si son dossier parent est accessible dans l’arborescence.
Organisation
Une convention est de nommer les volumes @myvol. Ce n’est pas une obligation de commencer par @, mais très fréquemment utilisé.
On peut choisir de créer les volumes à la racine du top-level puis de les monter au sein de / (volumes “flat”), ou bien de les créer directement au chemin où ils doivent être accessibles, imbriqués dans un autre volume (volumes “nested”).
L’organisation flat correspond assez bien au fonctionnement de btrbk (voir plus loin). Elle est aussi pratique pour avoir un bon aperçu des volumes utilisés au sein d’un FS, et pour s’assurer de leur bonne sauvegarde. Mais ils ont besoin d’être montés dans le fstab (ou autrement).
Le principal avantage que je vois aux volumes nested, c’est d’être directement au bon emplacement, tout en étant exclus des snapshots. Ça me semble bien pour les dossiers temporaires, avec de la donnée qui sera recréée automatiquement si elle est absente, comme les dossiers de cache. Pas besoin de les monter.
Quelques dossiers qui peuvent être intéressants à mettre en sous-volume :
/var/log/
/var/cache
$HOME/.cache
Swap
On peut faire un swapfile sur btrfs. Pour ça, il faut créer un sous-volume dédié et désactiver le CoW (voir plus bas) puis faire btrfs filesystem mkswapfile --size 2G ./swapfile
liste tous les volumes du FS btrfs.
L’argument doit être le point de montage, pas un sous-dossier ou un sous-volume.
Volume par défaut
Lorsqu’on monte simplement la partition BTRFS, sans plus de précision, c’est un certain volume qui sera monté. C’est généralement le volume top-level, avec un id de 5, mais ceci peut se vérifier et se changer.
sudo btrfs subvolume get-default /media/BTRFS
Suppression
sudo btrfs subvolume delete /path/to/@subvol
Il est possible que l’espace ne soit pas récupéré immédiatement (lié au no-commit ?).
On peut forcer la récupération avec la commande sync.
Il est possible de simplement rm -R /path/to/@subvol , mais c’est beaucoup plus long (chaque fichier est supprimé, alors que la suppression du volume est quasi-instantanée).
Snapshots
Un snapshot est simplement un volume, qui a été initialisé avec les données déjà présentes dans le volume source.
Pour les créer : sudo btrfs subvolume snapshot -r ./@sourcevol ./@snapshot/@backupvol
Le -r sert à mettre le snapshot en lecture seule. On peut l’enlever si on souhaite l’avoir en lecture-écriture.
Il est impératif que la destination soit sur le même FS btrfs.
Un snapshot ne prendra pas les données des sous-volumes nested !
Le volume nested se retrouve dans le snapshot avec un inode 2 ; il n’est pas listé dans les volumes du FS.
Il est transféré à nouveau sous forme d’inode 2 lors d’un snapshot depuis le snapshot.
Suppression
C’est un volume normal, donc btrfs subvolume delete.
Le Copy-on-Write permet d’assuer une meilleure intégrité des données, mais au prix d’une baisse de performance, et éventuellement de fragmentation.
Certains contextes bénéficient de la désactivation du CoW, notamment les gros fichiers et/ou à écriture très fréquentes.
Notamment, les VM et les bases de données : l’utilisation intensive favorise la fragmentation, dégrade les perfs, et peut grandement augmenter l’espace utilisé. Voir notamment l’espace UNREACHABLE dans btdu.
J’ai l’impression que le dossier ImapMail d’un profil Thunderbird peut aussi gagner à être mis en nodatacow (il peut être recréé à partir des serveurs si nécessaire).
Il est possible de désactiver le CoW lors du montage du volume, mais tous les volume du même FS seront alors montée en nodatacow (et donc nodatasum).
Une autre possibilité est de positionner l’attribut nodatacow sur un dossier (qui peut être un sous-volume).
L’attribut nodatacow sur btrfs est C.
Pour lister les attributs :
lsattr ./file
lsattr -d ./folder/
Pour positionner l’attribut nodatacow : chattr +C ./
S’il est positionné sur un dossier, alors tous les nouveaux fichiers crées dedans le possèderont aussi ; mais les fichiers existants ne seront pas affectés (sauf les fichiers vides).
Pour changer le status CoW d’un fichier, il y a l’obligation de le réécrire complètement.
Dynamiques de copie/déplacement
Lorsqu’on coupe/colle, il est possible que le fichier soit instantanément déplacé, ou bien qu’il doive être réécrit complètement.
Voici un petit tableau récapitulatif du comportement des transferts :
Pour la copie, la réécriture est directement liée au statut CoW du dossier de destination : s’il différe de celui du fichier, alors il y a réécriture.
Pour un déplacement, tant qu’on reste dans le même volume, le status CoW n’est pas modifié.
Mais dès que le volume change ET le dossier de destination a un statu CoW différente, alors il y a réécriture.
On note que 2 déplacements successifs peuvent produire un résultat différent d’un seul déplacement direct.
Mais si on le déplace d’abord dans cow, puis dans nocow, le changement de volume se passe sans changement de CoW, puis on reste dans le même volume ; les 2 transferts sont instantanés et on obtient :
L’objectif premier de balance est de rerépartir les données entre les différents devices pour s’assurer que cette répartition correspond bien au profil demandé (single, dup, raid etc).
Mais cette commande est aussi utilisée pour regrouper les données au sein des mêmes chunks, afin de vider et libérer des chunks.
Il faut que le système soit monté pour pouvoir faire une balance.
Il me semble que ça vaut le coup de mettre un btrfs balance start -dusage=10 / dans le crontab (de root) pour limiter les risques de saturation du disque.
Sur un SSD de 500G en fonctionnement depuis quelques mois, la première itération de balance a mis moins d’une minute. Les passes suivantes sont beaucoup plus rapides si faites régulièrement.
filtres
-m s’applique aux blocs (chunks) de metadata (et implicitement les blocs système), -d aux blocs de données et -s aux blocs système.
-musage=10 ou -dusage=10 : ne s’applique que sur les blocs qui sont remplis à moins de 10%
Le principe général de btrbk, c’est de lire un fichier de conf, et d’exécuter une/des actions selon ce fichier de config.
La config va définir une ou plusieurs sources, répertoires de snapshots et répertoires de backups.
Dans la terminologie btrbk, un “snapshot” est un snapshot btrfs en read-only (un versionning sur le même disque) ; et un “backup” est un sous-volume en read-only créé sur un autre FS btrfs via send/receive (la copie sur un 2e disque).
L’appel se fait sous la forme : btrbk -c /path/to/btrbk.conf [action] [filter] [-v] [-n] [-S] [--progress]
Les options -v (verbose) -n (dryrun, modifications non effectuées) et -S (pour afficher les raisons de conservation de chaque snapshot/backup) sont utiles pour mettre en place le fichier de conf et la rotation.
Il y a bien sûr d’autres options, mais celles-ci m’ont été très utiles.
Les actions peuvent être :
run : fait les snapshots, puis les backups, puis le nettoyage des versions
dryrun : montre les snapshots et les backups qui auraient été créés, mais sans rien écrire ; équivalent à run -n
snapshot : fait les snapshots et le nettoyage, ignore les backups
resume : ne crée aucun snapshot, mais fait les backups et le nettoyage de versions (snaps + backups)
prune : fait uniquement le nettoyage des versions
archive : copie récursivement tous les volumes depuis la source vers la cible (??)
clean : supprime les backups incorrects (qui ne se sont pas terminés avec succès)
Un récap de l’effet de chaque action est dispo dans le man :
Command Option S+ B+ S- B-
--------------------------------------------
run x x x x
run --preserve x x
run --preserve-snapshots x x x
run --preserve-backups x x x
snapshot x x
snapshot --preserve x
resume x x x
resume --preserve x
resume --preserve-snapshots x x
resume --preserve-backups x x
prune x x
prune --preserve-snapshots x
prune --preserve-backups x
D’autres commandes, informatives, sont disponibles : stats, list, usage, etc. Voir man
Quant au filtre, s’il est présent, va n’appliquer l’action demandée qu’aux sections concernées par le filtre.
Attention, il ne s’applique pas qu’au groupe ! Il s’applique aussi aux sections (target, volume et subvolume).
Ainsi, la section target /media/backup sera incluse dans le spectre du filtre backup.
btrbk.conf
man btrbk.conf
Les éléments de ce fichier de conf se séparent en 2 catégories :
les sections (volume, subvolume et target)
les options (qui spécifient le fonctionnement de btrbk)
Concernant les sections : volume est facultatif ; représente le chemin dans lequel on travaille. Pour une structure flat, c’est typiquement le point de montage du top-level ; si l’option est absente, il faut nécessairement mettre un chemin absolu pour l’option subvolume (et target ?) subvolume : le sous-volume (au qui sera snapshotté) ; typiquement @rootfs ou @home target : le dossier (autre FS btrfs) dans lequel sera transféré le snapshot, via send/receive ; s’il est absent, btrbk ne fera que des snapshots.
Les options sont nombreuses. Chaque option s’applique à la section à laquelle elle appartient, ainsi qu’à toutes les sections contenues dans celle-ci.
Par exemple, avec le fichier suivant :
l’option snapshot_dir s’applique à la section /btrfs_slash, et donc aussi aux 2 sections subvolume.
En revanche, l’option group et la sous-section target s’appliquent au sous-volume @rootfs uniquement.
snapshot_dir : le dossier qui contiendra les snapshots (local, même FS btrfs) créés par btrbk ; s’il est absent, le snapshot sera créé à côté du volume d’origine, mais avec la date ajoutée group : permet d’assigner une “catégorie” à une section, pour pouvoir ensuite l’appeler en filtrant ; le nommage est libre
conserver le 1er snapshot de la journée pendant 30 jours
conserver 1 snapshot par semaine pendant 12 semaines
conserver 1 snapshot par mois pendant 24 mois
conserver 1 snapshot par an
À noter qu’il peut y avoir moins de versions que le nombre spécifié, si certains snapshots ont été sautés. Par exemple, le nettoyage peut supprimer un snapshot vieux de 49h, même si il n’y a que 24 snapshots horaires car le poste était éteint pendant 24h.
Les valeurs _min sont définies par défaut à all, empêchant de fait un nettoyage des versions si on ne le spécifie pas.
En mettant latest, c’est l’opposé, on ne force que la conservation du dernier snapshot.
Nettoyage et target
En cas d’appel à une section incluant une section target, si le chemin de la target est introuvable (par ex. disque débranché), btrbk fera bien les snapshot, mais ne fera ni les backups, ni le nettoyage des snapshots ; et ce même si on appelle l’action snapshot.
Comme il ne connaît pas les backups présents sur la target, il conserve tous les snapshots en local, quel que soit la planification de backup prévue.
Si une tache est planifiée tous les jours voire toutes les heures, avec un disque de sauvegarde régulièrement débranché, les snapshots peuvent alors s’accumuler, et augemnter sensiblement l’espace disque occupé.
Si on souhaite effectuer le nettoyage des snapshots, même en l’absence du disque, on peut alors mentionner le même volume 2 fois, mais dans des groupes différents, et les appeler séparément. Par exemple :
volume /btrfs_slash
snapshot_dir @snapshots
subvolume @rootfs
group snap_only
subvolume @rootfs
group backup_only
snapshot_create no
target /media/user/BACKUP
permet de séparer l’appel des snapshots (avec nettoyage auto) de la partie backup (pour laquelle on désactive la création de snapshot).
Il suffira de choisir entre les filtres snap_only et backup_only.
Ceci risque de supprimer des snapshots avant qu’ils ne se retrouvent sur le disque externe en tant que backups, et donc de créer des trous dans l’historique des backups. Mais la possibilité existe, et permet un nettoyage automatique des snapshots pour éviter la saturation d’espace disque.
À noter que l’option snapshot_create no désactive la création de snapshot en cas d’appel run, mais un snapshot sera quand même créé si l’action appelée est snapshot.
Il analyse le FS en collectant des échantillons au hasard. Plus on le laisse tourner et + il est précis, mais il consomme beaucoup de CPU.
Il nécessite les droits root.
p pour mettre l’analyse en pause
--max-time=DURATION pour interrompre l’analyse après la durée spécifiée. Il faut spécifier l’unité (s, m, h, d … ) --headless pour ne pas avoir d’interface ; affiche les résultats en texte à la fin de l’exécution. Si pas de durée max, il faudra l’interrompre avec Ctrl-C --expert pour avoir des infos détaillées sur l’allocation de l’espace
On peut exporter les résultats pour les examiner plus tard, avec --export=results.btdu.
ATTENTION, si btdu est lancé avec l’interface, il faut quitter avec q et non Ctrl-C, sinon l’export n’est pas fait !
Il y a 2 formats d’enregistrement :
le format .btdu , qui contient l’intégralité des informations récupérées lors de l’analyse, mais est + volumineux
le format .json, avec moins d’infos (les infos enregistrées dépendent notamment du flag expert)
Le format est déduit de l’extension, ou spécifié avec --export-format
On peut aussi spécifier --du pour une sortie conforme au format de sortie de du.
On pourra rouvrir ce fichier plus tard en utilisant --import results.btdu au lieu du chemin. On peut appliquer des otions comme headless, expert etc.
Troubleshoot
No space left
On peut avoir le message d’erreur “Aucun espace disponible sur le périphérique” alors qu’il y a de la place sur le FS BTRFS.
Si on fait : sudo btrfs filesystem usage /
On voit Device unallocated: et c’est probablemnet à 0 ou presque. C’est l’espace qui est non alloué, nécessaire pour ajouter/modifier des données.
On voit aussi Free (estimated):, ce qui est de l’espace non utilsé, au sein de blocs déjà alloués. C’est cette métrique qu’on voit dans l’explorateur de fichier.
Comme beaucoup d’espace est libre au sein de blocs déjà alloués, on va utiliser balance pour vider entièrement certains blocs puis les supprimer, afin de récupérer de l’espace non alloué.
Ceci nécessite toutefois d’avoir de l’espace libre… Il faut donc commencer par supprimer/déplacer des données du FS d’abord, jusqu’à réussir à vider un bloc qui deviendra non alloué.
S’il est impossible de réussir à vider un bloc, une autre possibilité est d’ajouter de l’espace au FS ! On branche un disque, une clé USB etc., puis on fait une partition (quelques dizaines de Mo suffiront) non formatée, puis on fait sudo btrfs device add /dev/sdX1 /
On voit alors le device apparaître dans sudo btrfs filesystem show /, et dans sudo btrfs filesystem usage / .
On peut alor lancer un balance avec par exemple -dusage=1, qui pourra fonctionner.
Puis on supprime le device : sudo btrfs device remove /dev/sdX1 /
Une méthode pour prévenir ça est de faire régulièrement un balance
taille metadata ?
-> adaptative, à condition d’avoir de “Unallocated Space”
Voir les périphériques actuellement utilisés en swap
cat /proc/swaps
Voir les périphériques pouvant être utilisés en swap
## Identifier les processus qui utilisent du swap
Les résultats sont en ko (comme dans le fichier /proc/$PID/smaps)
#!/bin/bash
# Get current swap usage for all running processes
SUM=0
OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d | egrep "^/proc/[0-9]"` ; do
PID=`echo $DIR | cut -d / -f 3`
PROGNAME=`ps -p $PID -o comm --no-headers`
for SWAP in `grep Swap $DIR/smaps 2>/dev/null| awk '{ print $2 }'`
do
let SUM=$SUM+$SWAP
done
if [ ! $SUM = 0 ] ; then
echo "$SUM : Swap Used - ($PROGNAME ) PID=$PID"
fi
let OVERALL=$OVERALL+$SUM
SUM=0
done
echo "Overall swap used: $OVERALL"
Installer un .zip via adb sideload et “Install Zip” dans TWRP reviennent au même.
Un légère différence est que lors d’une installation via le fichier zip directement présent sur le tél, l’installeur connaît le nom du fichier, et peut dans certains cas modifier son comportement en fonction de ce nom. Par exemple, si le fichier magisk.zip est renommé uninstall.zip, alors l’installation de ce fichier entrainera la suppression de Magisk.
Une grosse partie des partitions sont en double, dans une version “A” et une version “B”. Ce sont des slots.
Le tél a un slot actif au démarrage, et n’utilisera que les partitions de ce slot.
Ceci permet la mise à jour OTA vers le slot inactif alors que le tél tourne sur le slot actif. Au redémarrage, le slot actif est changé et le boot se fait sur la nouvelle version.
En cas d’échec de démarrage 3 fois de suite, le slot est rechangé.
En exception notable, la partition data n’a qu’un seul exemplaire ; pour cette raison, il n’est pas possible (sans factory reset) de passer d’un OS à un autre OS différent en utilisant les 2 slots.
Consulter le slot actif
fastboot getvar current-slot
adb shell
getprop ro.boot.slot_suffix
Dans TWRP, section “Reboot”.
Dans LOS recovery, affiché en haut.
Changer le slot actif
fastboot --set-active=b
Dans TWRP, section “Reboot”, bouton A ou B.
Pour les Sony, en mode flash, avec newflasher : newflasher set_active:a
boot et recovery
Dans les devices A/B, le recovery n’est plus une partition à part entière, mais fait partie de la partition boot.
Pour cette raison, la commande fastboot flash recovery ./recovery.img ne fonctionne pas, car recovery n’est pas une cible valide.
De même, pour un recovery différent du recovery de l’OS installé (par exemple TWRP), la commande fastboot flash boot ./recovery.img fonctionne, mais va empêcher le système de boot car sa partition boot est cassée. Seul le recovery sera bootable.
Pour installer TWRP, il faut donc copier télécharger twrp-installer.zip puis l’installer via adb sideload. Ça peut être fait depuis le recovery de LineageOS, ou bien on peut booter temporairement TWRP depuis le mode fastboot, via fastboot boot ./twrp.img
pour installer twrp-installer.zip depuis “Install” ou bien “ADB Sideload”. L’installer écrit TWRP sur la zone recovery des 2 slots “boot” sans toucher au reste du boot.
Si la VoLTE est active, lorsqu’on passe un appel, l’indicateur reste en 4G/LTE ; sinon il repasse en 3G/H+.
Sous LineageOS, lorsque la VoLTE est active, un petit logo “HD” apparaît lors de l’appel.
Attention, en cas d’appel sortant, il n’apparaît qu’une fois la communication établie ; il est absent durant la tonalité.
*#*#4636#*#*
Infos sur le téléphone -> ... (haut-droite) -> État du service IMS
Ne PAS se fier à "Type de réseau vocal" dans les infos tél
Paramètres -> Réseau et Internet -> SIM -> choisir la SIM -> Type de réseau préféré
WCDMA = H+ , appels 3G
TDSCDMA = pas d’appel
