https://docs.pikvm.org/v4/

update :
pikvm-update

Reprendre copie

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.

Attention, il faut lancer

xattrs

Pour consulter

https://stackoverflow.com/questions/36819474/how-can-i-attach-a-vhdx-or-vhd-file-in-linux

Installation :

sudo apt-get install libguestfs-tools

Montage :

# 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

Pour démonter l’image :
guestunmount /mnt

Général

https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/Main_Page.html

Se gère avec la commande btrfs et ses sous-commandes.
Penser à
man btrfs subcommand

Les données sont organisées sous forme de “chunks” ou “blocs”, qui sont par défaut de 1Go.

Installation

sudo apt install btrfs-progs

Formatage et label

sudo mkfs.btrfs /dev/sdX1 -L "Label"
btrfs filesystem label /media/BTRFS ["Nouveau label"]

Infos

sudo btrfs filesystem show /media/BTRFS

Utilisation espace

btrfs filesystem df /media/BTRFS
btrfs filesystem df /media/BTRFS
sudo btrfs filesystem usage

Attention, d’autres outils peuvent renvoyer des infos incorrectes.
Comme ncdu qui ne prend pas en compte la deduplication.

Vérification

btrfs check /dev/sdX

man btrfs check

Volumes

https://man7.org/linux/man-pages/man8/btrfs-subvolume.8.html

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

Lister les volumes

sudo btrfs subvolume list /media/BTRFS

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

RO / RW

btrfs property get ./mysubvol/

btrfs property set ./mysubvol ro false

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).

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

https://btrfs.readthedocs.io/en/latest/Swapfile.html

Flags

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.

Deduplication

https://btrfs.readthedocs.io/en/latest/Deduplication.html

send et receive

send ne peut être utilisé que sur un sous-volume.

CoW et limitations

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 statut CoW n’est pas modifié.
Mais dès que le volume change ET le dossier de destination a un statut 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.

Par exemple, si on a l’arborescence :

---------------------- @cow/
---------------------- @cow/TEST.iso
---------------------- cow/
---------------C------ @nocow/
---------------C------ nocow/

et qu’on déplace TEST directement dans nocow, il est intégralement réécrit et on obtient :

---------------------- @cow
---------------------- cow
---------------C------ @nocow
---------------C------ nocow
---------------C------ nocow/TEST.iso

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 :

---------------------- @cow
---------------------- cow
---------------C------ @nocow
---------------C------ nocow
---------------------- nocow/TEST.iso

balance

sudo btrfs balance
man btrfs balance

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%

btrbk

https://github.com/digint/btrbk

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), -vv (très 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
subvolume : le sous-volume qui sera snapshotté ; typiquement @rootfs ou @home
target : doit être un chemin absolu : indique volume dans lequel sera transféré le snapshot, via send/receive ; s’il est absent, btrbk ne fera que des snapshots. IL peut être sur le même FS ou sur un autre.

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 :

volume /btrfs_slash
 snapshot_dir @snapshots
 subvolume @rootfs
  group snap
  target /media/user/BACKUP
 subvolume @log

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

Durée de conservation

Celle-ci se définit via les options :

snapshot_preserve_min   latest
snapshot_preserve       48h 30d 12w 24m *y
target_preserve_min   latest
target_preserve       0h 60d 20w 24m *y

À lire, pour les snapshots par exemple :

• conserver 1 snapshot par heure pendant 48h
• 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.

SSH

On peut utiliser un hôte distant comme source (volume ) et/ou destination (target).
btrbk n’a pas besoin d’être installé sur le poste distant, mais il faut avoir les outils btrfs installés et avoir les droits d’accès au FS (donc basiquement être root).

Si le

La syntaxe :

volume ssh://myremotehost[:port]/btrfs_part/
  subvolume @rootfs
    snapshot_dir TEST
    target ssh://myremotehost/media/user/backup

Le snapshot_dir est dans le contexte du volume, donc ici c’est root@myremotehost:/myremotehost/btrfs_part/TEST/

Il ne faut PAS mettre le nom d’utilisateur dans le chemin. Par défaut c’est root, mais si besoin de le spécifier :

    ssh_user root

Si l’environnement bash distant est personnalisé (echo, etc), il est possible que ça génère une erreur
Target "myremotehost:/media/user/BACKUP" aborted: Failed to fetch subvolume detail

En ce cas, mettre au début du bashrc :

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

btdu

Utilitaire 3d party pour un genre de ncdu
https://github.com/CyberShadow/btdu/

Il analyse le FS en collectant des échantillons au hasard. Plus on le laisse tourner et + il est précis, mais il prend tout le CPU dispo.
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

compression - compsize

taille metadata ?
-> adaptative, à condition d’avoir de “Unallocated Space”

https://mpdesouza.com/blog/btrfs-for-mere-mortals-inode-allocation/

https://superuser.com/questions/1677225/check-which-processes-are-eating-swap-on-linux

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"

https://www.liquidweb.com/help-docs/server-administration/linux/identifying-which-processes-are-using-swap-memory/

sudo apt install swaks

Failed to load module “atk-bridge”: ‘gtk_module_display_init’: /usr/lib/x86_64-linux-gnu/gtk-2.0/modules/libgail.so: undefined symbol: gtk_module_display_init apt install libatk-adaptor

Affichage graphique en root

Quand on fait sudo su - on ne peut pas lancer les programmes graphiques.
Pour le permettre :

Depuis la session hôte graphique :
xhost +local:

depuis la session su :
export DISPLAY=:0

Flexible I/O tester, soit fio, sert à spécifier des charges de travail précises à faire exécuter par des supports de stockage.

sudo apt install fio

Liens :
https://fio.readthedocs.io/en/latest/fio_doc.html
https://linux.die.net/man/1/fio
https://askubuntu.com/questions/87035/how-to-check-hard-disk-performance
https://arstechnica.com/gadgets/2020/02/how-fast-are-your-disks-find-out-the-open-source-way-with-fio/
https://www.virtono.com/community/tutorial-how-to/fio-basics/

Paramètres obligatoires :
--name : le nom du job
--size : la taille du fichier ; obligatoire s’il n’existe pas déjà un fichier ou périphérique à l’emplacement de “filename” ; on peut toutefois une taille inférieure à l’objet existant, et seule cette zone sera utilisée pour le test

Par défaut, c’est un test en lecture seule sur un fichier de 4G.
Attention, si la taille est élevée, elle peut mener à une consommation de RAM élevée par job qui utilise des accès random (randread, randwrite et randrw) ! Dans le cas d’un RAID de 40 To, chaque job consommait environ 1.3 Go de RAM. Si on multiplie les jobs, cela peut mener à l’OOM.
Je suppose que c’est lié au fait qu’il va essayer de répartir les tests sur l’intégralité de la surface du périphérique, qu’il doit donc “mapper”.
Si on spécifie une taille sensiblement plus petite, alors ce problème ne se manifeste pas. Mais cela ne teste le support de stockage que sur une plus petite surface (donc moins de mouvement mécanique, et des résultats plus élevés que des accès sur toutes la surface).
io_size n’a pas d’effet dessus ; c’est size qui importe.

Autres paramètres :

--filename : le fichier (ou bloc ! ) sur lequel sera réalisé le test ; par défaut, c’est ./${jobname} (la valeur de –name) si un seul job, ou jobname.jobnumber.filenumber si plusieurs jobs
--filename_format : permet de personnaliser la génération de filename

--readonly pour de la lecture seule
--readwrite (ou –rw) : définit le type d’opération : read (séquentiel) , write (séquentiel) , randread (aléatoire) , randwrite (aléatoire) , rw (50/50 séquentiel) , randrw (50/50 aléatoire)
--opendir : ouvre séquentiellement tous les fichiers sous le répertoire passé en argument

--io_size : définit la quantité de données à traiter avant d’arrêter fio. Par défaut c’est équivalent à size, mais peut être différent (par exemple pour lire uniquement 5G de données malgré une taille de fichier de 20G, ou à l’inverse lire un total de 10G malgré une taile de fichier de 500m ; en cas il boucle)
--blocksize : par défaut 4096
--ioengine : le moteur d’I/O à utiliser ; par défaut psync ; voir les descriptions ; beaucoup d’exemples semblent utiliser libaio
--fsync= : pour forcer une sync (écriture réelle sur le périphérique) après X écritures
--end_fsync=1 : pour que le timer continue jusqu’à ce que l’OS rapporte que les écritures ont réellement été réalisées
--direct : force la non-utilisation d’un buffer disque ; recommandé de toujours mettre 1 (true)
--refill-buffers : pour forcer le renouvellement des données aléatoires utilisées pour le test

--gtod_reduce=1 : semble réduire les requêtes pour connaître l’heure et améliorer les perfs
--eta-newline : force l’affichage d’une nouvelle ligne après X secondes

En cas de lecture seule, le fichier de test doit être au moins aussi gros que la taille de blocs par défaut (soit 4K).

Bruit et conso

Ces tests peuvent être une bonne manière de tester le bruit et la conso éléctrique d’un disque ; dans mon expérience, les accès aléatoires (que ce soit lecture ou écriture) sont particulièrement bruyants, alors que les accès séquentiels sont quasi inaudibles.

Job files

Syntaxe

; -- start job file --
[global]
rw=randread
size=128m

[job1]

[job2]

; -- end job file --

Chaque jobfile peut contenir 1 ou plusieurs jobs. Si plusieurs présents, il sont parallélisés.
On peut éviter cette parallélisation avec l’option stonewall (ou wait_for_previous) : un job qui possède cette option attendra la fin du/des jobs précédents avant de démarrer. Ce job (et les suivants) feront aussi partie d’un nouveau groupe de rapport.

Chaque job peut également paralléliser des IO (via iodepth ou numjobs).
On peut également fournir plusieurs jobfiles en ligne de commandes, et ils seront exécutés à la suite.

–section
possible de mettre des variables

Utilisation

Pour tester un disque en tant que bloc :
fio --filename=/dev/sdX ./jobfile.txt
Pour écrire le log dans un fichier :
fio --filename=/dev/sdX --output=mydisk.log ./jobfile.txt

Output

https://fio.readthedocs.io/en/latest/fio_doc.html#interpreting-the-output

Au début, le nom de tous les jobs qui seront lancés, avec leurs options.

seqread: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
randread: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
randwrite: (g=1): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1

g= : leur groupe d’appartenance (je suppose) ; (R) (W) (T) : read write trim

Pendant le test, Une ligne de type :
Jobs: 1 (f=1): [_(1),r(1),P(1)][45.4%][r=20.9MiB/s][r=5350 IOPS][eta 00m:53s]
Jobs: 1 (f=1) : le nombre jobs en cours dans le groupe (f=nombre de fichiers ouverts)
[_(1),r(1),P(1)] : l’état de l’ensemble des jobs prévus ; voir table dans la doc pour + de détails ;
les principaux états : _ = correctement fini ; rwmdRWMD : read/write/mixed/trim (MAJ=seq,min=rand) ;
P = job planifié pour plus tard ; X = erreurs ; K = interrompu
Puis pour chaque test (ou groupe si group_reporting) :

• des infos test1: (groupid=0, jobs=1): err= 0: pid=1519610: Sun Feb 25 11:25:53 2024
• des valeurs de latences (slat = submission latency, clat = completion latency, lat = total latency)
• des valeurs de bande passante et d’IOPS
• statistiques sur la latence, les IOPS, la bande passante etc

bench-fio et fio-plot

Un programme existe, fio-plot, qui permet de faire des graphs en utilisant les résultats de fio comme source de données.
Git : https://github.com/louwrentius/fio-plot qd Il est nécessaire que les données soient au format JSON, et que l’arborescence suive une formé précise.

Le + simple pour les créer semble être d’utiliser le script bench-fio fourni avec fio-plot.

Installation

Ne semble pas dispo dans les dépôts Debian.
Les instructions disent d’utiliser pip3 pour l’installer, mais Debian (trixie) m’informe que c’est mieux avec pipx. Donc on y va :
pipx install fio-plot

Les binaires se trouvent dans ${HOME}/.local/bin/ , et sont en fait des liens vers ${HOME}/.local/share/pipx/vens/fio-plot/. On y trouve notamment bench-fio et fio-plot.

Le chemin devrait être dans le ${PATH}, mais si besoin de lancer en root, il faudra sûrement donner le chemin complet.

Utilisation

bench-fio est un wrapper autour de fio. Il utilise un fichier INI qui définit les combinaisons à tester pour une même cible (fichier, périphérique etc…).

Dans le cas d’un RAID, en RAW (attention destruction de données), ce fichier INI pourrait être :

[benchfio]
output = ./results

# si on travaille sur un périphérique bloc
target = /dev/sdX
type = device
## on peut spécifier la taille ; par défaut c'est tout le device
#size=10G
## on peut choisir de travailler au début ou à la fin du périphérique avec offset
## la zone comprise dans offset sera ignorée pour le test
#extra_opts = offset=119G

## sinon on peut travailler sur un ficher ; 
#target = /mountpoint/file
#type = file
## dans ce cas la taille doit être spécifiée
#size = 500G
## il faut que le fichier existe déjà
## si la taille est différente de ce qui est demandé, le fichier est intégralement écrit avant le début des tests, ce qui peut être très long
## on peut créer le fichier à l'avance avec une commande :
## fio --name=preparation --filename=/ZFS/TMP --rw=write --bs=1M --size=500G --direct=1 --ioengine=libaio --buffer_compress_percentage=0 --refill_buffers



## par défaut le test s'arrête au bout de 30 secondes ; on augmente à 300s
runtime = 300
# on peut aussi désactiver le timer
#runtime = 0

## on choisit les combinaisons que l'on veut tester
## l'ordre peut avoir une importance en matière de gestion du cache
mode = randread,randwrite,randrw,rw,read,write
rwmixread=60

numjobs = 1,10,25
block_size = 4k, 64k, 1M

## HDD
iodepth = 1,64,512
## SSD
#iodepth = 1,16,64


direct = 1
engine = libaio
precondition = False
precondition_repeat = False
destructive = True

## opts pour que les données soient différentes à chaque itération (pour éviter l'effet cache) et ne soient pas compressibles
refill_buffers = 1
buffer_compress_percentage = 0
invalidate = 1
## invalidate devrait être activé par défaut

type doit nécessairement être défini. Il peut s’agir, entre autres, de directory, device, file ou rbd (lié à Ceph).

Certaines valeurs sont définies par défaut ; notamment le runtime, qui si non spécifié, est de 60 secondes, soit 1 minute max par test ; je l’ai monté ici à 300s (5 minutes).
Chaque test se finit dès que la taille spécifiée est traitée OU que le temps de runtime s’est écoulé.

Le paramètre “invalidate” de fio est par défaut à 1, c’est-à-dire que le cache est invalidé avant chaque test. Mais pour ceci, si la cible est de type “device”, il est nécessaire d’être root pour pouvoir invalider le cache.

Pour lancer le bench, il suffit de faire bench-fio ./bench.ini.
Ceci va nous créer (dans le dossier actuel) un dossier ${output}/${target}/${block_size} ; donc ici results/md0/4k , qui contiendra des fichiers JSON de type $mode-$iodepth-$numjob , par exemple “read-16-32.json”, ainsi qu’un fichier .log pour chaque job de chaque test ! Ça peut donc vite se compter en 10aines de milliers si on met beaucoup de combinaisons.

Choix des valeurs

Dans mon expérience :

Sur un SSD NVMe performant (Samsung 990 Pro),

• il est inutile de monter depth au-delà de 64 ; même avec 1 seul job, il n’y a aucun gain
• une taille de secteur de 4k donne des meilleurs résultats que 16k, et + stables, sauf sur

Génération des graphs

Une fois que le benchmark est fini, on peut genérer un graph avec fio-plot .
La syntaxe minimale doit inclure le dossier ou chercher les résultats (source des graphs) avec -i, le titre du graph avec -T, la mesure (read, randwrite etc) à laquelle on s’intéresse avec -r et le type de graph ; par exemple :
fio-plot -i results/md0/4k -T MONSUPERGRAPH -r read -l
En l’absence de précisions, il va chercher les valeurs pour les queue depths 1 2 4 8 16 32 64 et uniquement 1 en numjob.
Si une de ces combinaison est manquante dans les les données, la création de l’image échouera. On peut alors préciser ces valeurs avec -d pour depth et -n ; selon le type de graph, il peut être possible de séparer plusieurs valeurs par des espaces ; par exemple :
-d 1 4 16 64 -n 2 16 32

Les types de graph sont :

• -l pour un graph 2D avec des barres représentant les IOPS et la latency, selon la queue depth (1 seul numjob par graph)
• -N pour un graph 2D avec des barres représentant les IOPS et la latency, selon le numjob (1 seul queue depth par graph)
• -L pour un graph 3D avec des barres représentant, au choix grace à l’option -t, les IOPS, ou la latence (lat, slat, clat) ou le débit ; les valeurs possibles sont bw,iops,lat,slat,clat ; on peut cumuler les valeurs de queue depth et numjob
• -H pour un histogramme (quel pourcentage des valeurs est contenu dans chaque tranche de valeur) de la latence ; 1 depth et 1 numjob par graph (si on en spécifie plusieurs, seule la première valeur est prise en compte)
• -g pour des courbes en fonction du temps ; on choisit une métrique avec -t (parmi bw,iops,lat,slat,clat) et autant de numjobs et qd que souhaité ; on aura 1 courbe par combinaison de qd et nj

À ma connaissance, seuls les graph -L et -g permettent de voir la bande passante en MO/s.

BitLocker est un système de chiffrement de périphérique. Le contenu d’une partition est chiffré grâce à la FVEK (Full-Volume Encryption Key), elle-même chiffrée par la VMK (Volume Master Key), elle-même pouvant être chiffrée par différents moyens (les “protecteurs”, par exemple un password, ou le TPM).

Si il y’a un triangle jaune sur un périphérique, c’est que BitLocker n’est pas réellement activé. Les données sont chiffrées, mais aucun protecteur n’est en place pour protéger la clé de déchiffrement.

Lors d’une installation Windows sur un poste possédant une puce TPM, l’installation sera automatiquement (à vérifier ?) chiffrée pour utiliser Bitlocker.

Bitlocker se gère via le panneau de configuration (sur un Win10 Famille, c’est “Chiffrement de l’appareil)” ou en CLI avec manage-bde.

en CLI

Sous Windows avec le disque déverrouillé :
manage-bde -status
manage-bde -protectors C: -get

Si pas de protecteurs, on peut simplement désactiver le chiffrement avec
manage-bde -off LETTER:
Ça prendra un certain temps, pour réécrire les données non-chiffrées.

Linux

Si on veut accéder à cette partition depuis Linux, il faut utiliser l’outil dislocker, disponible dans les dépôts Debian.
sudo apt install disklocker

Cette ligne crée un nouveau document dont le nom suffixé de “-grayscale” input=mycolordoc.pdf output=$(echo "$input" | sed 's/.pdf$/-grayscale.pdf/') gs -sDEVICE=pdfwrite -sColorConversionStrategy=Gray -dProcessColorModel=/DeviceGray -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -sOutputFile="${output}" "${input}"

https://superuser.com/questions/104656/convert-a-pdf-to-greyscale-on-the-command-line-in-floss