Limite pratique du nombre d'instantanés btrfs?

J'envisage d'utiliser btrfs sur mon lecteur de données pour pouvoir utiliser Snapper , ou quelque chose comme Snapper, pour prendre des instantanés basés sur le temps. Je pense que cela me permettra de parcourir les anciennes versions de mes données. Cela s'ajouterait à ma sauvegarde hors site actuelle, car une panne de disque effacerait les données et les instantanés.

D'après ma compréhension, les instantanés btrfs ne prennent pas beaucoup de place (métadonnées et blocs qui ont changé, plus peut-être des frais généraux), donc l'espace ne semble pas être une contrainte.

Si j'ai un million d'instantanés (par exemple, un instantané toutes les minutes pendant deux ans), cela causerait-il des ravages, en supposant que j'ai suffisamment d'espace disque pour les données, les données modifiées et les métadonnées?

S'il existe une limite pratique au nombre de clichés, cela dépend-il du nombre de fichiers et / ou de la taille des fichiers?

En tant que personne qui utilise un btrfssystème de fichiers avec Arch Linuxdepuis presque des 2années maintenant, je peux dire sans risque qu'il ne semble pas y avoir de limite pratique sur le nombre d'instantanés qui peuvent être facilement atteints. Il y a cependant quelques mises en garde. btrfsle système de fichiers peut entraîner une fragmentation. Il est donc conseillé d'utiliser la fonction de défragmentation en ligne intégrée à btrfs. De plus, on peut faire bon usage de btrfsla fonction de compression de. Ces mesures devraient prendre en charge la plupart des problèmes de performances susceptibles de survenir raisonnablement sur un ordinateur raisonnablement décent lors de la création de nombreux instantanés.

Comme vous le savez peut-être, btrfstraite les sous-volumes comme des systèmes de fichiers et donc le nombre d'instantanés est en effet limité: notamment par la taille des fichiers. Selon le btrfswiki, la taille maximale de fichier pouvant être atteinte est 2^64 byte == 16 EiB^[1] .

En dehors de ces limitations, il peut toujours y avoir des problèmes lorsque vous manquez d'espace sans que vous le reconnaissiez immédiatement car la vérification de l'espace libre sur les btrfssystèmes de fichiers peut parfois être délicate, c'est-à-dire sans pouvoir différencier les différentes méthodes de mesure de l'espace libre sur un btrfssystème de fichiers. utilisez facilement la trace de la quantité d'espace restant. Une façon possible d'éviter ce scénario est l'utilisation de quotas. Cela garantit que les utilisateurs (ou l'utilisateur s'il n'en est qu'un) ne peuvent utiliser qu'une certaine quantité d'espace. Ce concept est discuté très habilement ici et aussi ici .

Dernier point mais non le moindre, un avertissement: je ne suis pas un expert des btrfssystèmes de fichiers et je n'ai lu ces informations que lorsque j'ai posé la même question il y a quelque temps. De plus, il y a toujours le problème qui btrfsest une "cible qui se déplace rapidement" (une belle formulation volée sur une Arch Linuxpage wiki je pense.) Donc les choses pourraient changer.

Bien qu'il n'y ait techniquement aucune limite sur le nombre d'instantanés, j'ai demandé sur la liste de diffusion BTRFS :

La réponse (pratique) dépend dans une certaine mesure de la façon dont vous utilisez btrfs.

Btrfs a des problèmes de mise à l'échelle en raison d'un trop grand nombre de snapshots (ou en fait les instantanés de reflinks utilisent, la déduplication à l'aide de reflinks peut déclencher les mêmes problèmes de mise à l'échelle), et un à deux chiffres à deux chiffres de snapshots par sous-volume de snapshotts reste la recommandation forte pour cette raison.

Mais les problèmes de mise à l'échelle affectent principalement les commandes de maintenance btrfs elles-mêmes, l'équilibre, la vérification, la suppression de sous-volume. Alors que des millions d'instantanés rendront l'équilibre par exemple effectivement inutilisable (cela fonctionnera en quelque sorte mais pourrait prendre des mois), les opérations normales du système de fichiers comme la lecture et l'enregistrement de fichiers n'ont pas tendance à être affectées, sauf dans la mesure où la fragmentation devient un problème ( les systèmes de fichiers de vache tels que btrfs sont notés pour la fragmentation, à moins que des mesures comme la défragmentation ne soient prises pour la réduire).

Il semble que l'utilisation d'instantanés comme sauvegarde d'archivage similaire à Time Machine / Snapper n'est pas une bonne idée.

Vous pouvez avoir un total combiné de 2 ⁶⁴ instantanés et sous-volumes.

La btrfspage wiki de conception dit (empahsis mine):

Les sous-volumes sont essentiellement un btree nommé qui contient des fichiers et des répertoires. Ils ont des inodes à l'intérieur de l'arbre des racines des arbres et peuvent avoir des propriétaires et des groupes non root. Les sous-volumes peuvent recevoir un quota de blocs et, une fois ce quota atteint, aucune nouvelle écriture n'est autorisée. Tous les blocs et extensions de fichiers à l'intérieur des sous-volumes sont comptés par référence pour permettre la capture instantanée. Jusqu'à 2 ⁶⁴ sous-volumes peuvent être créés sur le FS.

Les instantanés sont identiques aux sous - volumes , mais leur bloc racine est initialement partagé avec un autre sous-volume. Lorsque l'instantané est pris, le nombre de références sur le bloc racine est augmenté et le système de transaction de copie en écriture garantit que les modifications apportées dans l'instantané ou le sous-volume source sont privées à cette racine. Les instantanés sont accessibles en écriture et peuvent être instantanés à nouveau un certain nombre de fois. Si des instantanés en lecture seule sont souhaités, leur quota de blocs est défini sur un au moment de la création.