Geekly articles weekly

Quel est le problème avec la copie sur écriture pour Linux lors de la copie



Avertissement: cet article s'applique à tous les systèmes de fichiers CoW sous Linux qui prennent en charge la redistribution lors de la copie. Pour le moment, ce sont: BTRFS, XFS et OCFS2.

Veuillez vous abstenir de holivars sur lequel FS est le meilleur: Btrfs, XFS, Reiser4, NILFS2, ZFS ou certains non mentionnés.

Contexte


  • 21 juillet 2001 - Namesys publie l' annonce de Reiser4 . DARPA parraine le développement.
  • 20 novembre 2003 - Namesys publie quelques benchmarks Reiser4 .
  • 24 août 2004 - Namesys lance une version publique de Reiser4 .
  • 14 septembre 2004 - Annonce de ZFS.
  • 16 novembre 2005 - ZFS est inclus dans OpenSolaris build 27.
  • Septembre 2006 - Hans Reiser arrêté pour avoir tué sa femme, Nina Reiser. Début de la fin de Namesys
  • 12 juin 2007 - Annonce de Btrfs par Chris Mason (ancien employé de Namesys).
  • 22 septembre 2011 - Un ticket avec une demande d'implémentation de reflink est apparu dans ZFSonLinux.
  • 2012 - Btrfs reconnu comme stable Oracle Linux et SUSE Linux Enterprise
  • 21 janvier 2013 - le libellé de l'expérience a été supprimé avec Btrfs dans le code source du noyau Linux.
  • Mai 2019 - Btrfs supprimé de RHEL 8 (raisons politiques cachées soupçonnées d'être des Btrfs promues par Oracle)

Copier les attentes dans les systèmes de fichiers CoW


Lorsque Reiser4 a été annoncé en 2001, j'étais inspiré et passionné par la copie sur écriture. Pensez-y, nous pouvons facilement et simplement avoir autant de copies de différents projets que vous le souhaitez, et physiquement, le disque ne stockera que les différences entre eux!

De plus, la vitesse de copie devrait croître indécemment. En raison du fait que lors de la copie, seul un lien de redistribution vers l'ancien fichier sera créé. Lors de l'écriture dans un nouveau fichier, les secteurs des données modifiées seraient automatiquement alloués. Par conséquent, nous aurions les mêmes secteurs pour les parties communes des fichiers et différentes parties seraient enregistrées dans différents secteurs.

Cela ressemblait alors à une panacée pour créer des comptes pour l'hébergement partagé, et c'est maintenant la meilleure solution pour les machines et conteneurs virtuels légers. Après tout, nous ne pouvions pas perdre de l'espace sur des fichiers identiques, tout en permettant aux utilisateurs de les modifier facilement.

Cependant, Hans Riser est allé sur le toit et a tué sa femme, et son idée originale (probablement pour des raisons politiques) n'a pas été incluse dans le noyau. Peut-être qu'après tout, l'histoire dépend d'une personne en particulier?

ZFS a été publié sous une licence incompatible avec Linux et n'a donc pas été inclus dans le noyau. Par conséquent, l'introduction de ZFS sous Linux a été ralentie pendant longtemps.

Après cela, j'ai commencé à attendre Btrfs. Et seulement 6 ans après l'annonce, il a été reconnu par les développeurs du noyau Linux comme stable.

Après cela, je n'étais pas pressé d'utiliser les systèmes Cow, car le paradigme Copy-on-Write lui-même implique une fragmentation accrue, car les changements de données sont écrits à un nouvel endroit à chaque fois.

Pour le disque dur, la fragmentation tue les performances, car le processus de repositionnement du bloc de têtes de lecture est une opération très longue.

Par conséquent, j'ai personnellement reporté la mise en œuvre de btrfs sur mes machines jusqu'à ce qu'elles passent au SSD.

Je note que les SSD n'aiment pas non plus la fragmentation, tout le monde sait que pour un SSD, l'écriture / lecture linéaire peut être des dizaines de fois plus rapide que l'accès aléatoire.

Mais les performances d'un SSD fragmenté ne sont pas aussi spectaculaires que celles d'un disque dur.

Et la vitesse de copie avec CoW?


Et enfin, le moment est venu. Lorsque les SSD sont devenus suffisamment fiables, j'ai commencé à utiliser les systèmes de fichiers CoW avec force et force. Plus précisément, Btrfs et Nilfs2.

Maîtrisant les possibilités passionnantes des instantanés, j'ai oublié pendant un certain temps mes attentes des années 2000 concernant la copie ultra-rapide de fichiers.

Après un certain temps, j'ai décidé de faire des tests. Et à ma grande déception, je n'ai vu aucune augmentation de vitesse de CoW lors de la copie. Voici le résultat sur un SSD SATA:

time cp -a /usr /usr1 real 0m15,572s user 0m0,240s sys 0m4,739s

Il s'est avéré que pour utiliser CoW, vous devez spécifier une clé spéciale.

 time cp -a --reflink=auto /usr /usr2 real 0m3,166s user 0m0,178s sys 0m2,891s

Seulement dans ce cas, nous voyons un avantage 5 fois. Soit dit en passant, la taille de l'avantage augmente indéfiniment avec l'augmentation de la longueur du fichier. Le dossier /usr que j'ai copié est principalement de petits fichiers.

J'ai été incroyablement surpris de constater que l'avantage clé du système de fichiers CoW n'est pas utilisé par défaut. En effet, pour cela elle a été créée!

Dans ce cas, j'ai testé la copie sur la section Btrfs. Mais vous obtiendrez un résultat similaire avec tout autre système de fichiers CoW qui prend en charge le reflink.

Quel est le problème, Billy?


Le problème est en cp. Par défaut, il n'utilise pas CoW lors de la copie. Bien que ce soit possible.

Vous pouvez dire - je n'utilise pas cp. Cependant, sous le capot de Linux, il est utilisé presque partout. De nombreux programmes, lorsqu'ils ont besoin de copier quelque chose, utilisent cp , et non leurs "vélos".

Pourquoi les développeurs de coreutils ont-ils pris une décision aussi ambiguë, qui a barré la moitié des avantages des systèmes de fichiers CoW?

Il s'avère que c'est ce qu'a décidé Pádraig Brady, responsable du développement de GNU coreutils.

Voici sa logique :

  1. Par défaut, cp n'utilise pas CoW, car quelqu'un peut utiliser la copie afin d'augmenter la probabilité d'enregistrer le fichier sur le disque après la destruction du système de fichiers.
  2. En termes de performances, s'il existe une sorte de processus sensible au délai, vous souhaiterez peut-être que l'enregistrement principal soit effectué pendant la copie, donc si cela se produit plus tard, il peut y avoir un décalage lors du repositionnement des têtes du disque dur. Veuillez noter qu'à partir de la version 8.24 coreutils, mv utilise l'option reflink par défaut.

Pádraig Brady répond au texte en anglais
Ce n'est pas la valeur par défaut car pour des raisons de robustesse, on peut souhaiter qu'une copie soit effectuée pour se protéger contre la corruption des données. Aussi, pour des raisons de performances, vous souhaiterez peut-être que les écritures se produisent au moment de la copie plutôt qu'un processus sensible à la latence travaillant sur un fichier CoW et retardé par les écritures, éventuellement sur une autre partie d'un disque mécanique. Notez que à partir de coreutils v8.24 mv reflink par défaut, car il n'a pas les contraintes ci-dessus.

En termes de vitesse pour mv, il n'y a pratiquement aucun avantage de CoW lors du déplacement de fichiers. Dans un système de fichiers unique, mv fonctionne presque toujours très rapidement.

Encore une fois, la question se pose de l'influence de la personnalité sur l'histoire. En plaçant plusieurs lettres dans le code source du programme différemment, vous pouvez ralentir la copie pour des dizaines / centaines de millions d'utilisateurs (ici, vous devez considérer que la plupart des gens utilisent désormais les services cloud sous une forme ou une autre, même s'ils n'ont pas d'ordinateur), réduire l'efficacité de l'utilisation des lecteurs et augmenter leurs ventes dans le monde entier.

Analyse des arguments de Pádraig


Le premier argument est logique. Les utilisateurs inexpérimentés peuvent réellement sauvegarder des fichiers précieux sur le même système de fichiers.

Deuxième argument. Si vous lisez d'autres commentaires sur les décalages de Pádraig, vous constaterez qu'il avait en tête des situations de base de données où lors de l'écriture dans un fichier existant, il peut y avoir un retard dû au système de fichiers à la recherche d'espace libre. Mais dans le cas du système de fichiers CoW, de nouveaux secteurs seront toujours recherchés pour l'enregistrement en raison de la nature de CoW, comme l'a noté Jan Kanis. Par conséquent, à mon avis, le deuxième argument est intenable.

Cependant, sur les systèmes CoW, il est en effet possible d'obtenir un retard voire l'erreur «Out of space» lors de l'écriture dans le fichier de la base de données. Pour éviter cela, vous devez d'abord créer un répertoire vide avec CoW désactivé pour la base de données.

Désactivez CoW sur le répertoire / fichier comme ceci:

 chattr +C /dir/file chattr +C /dir/dir

Il y a aussi la possibilité de monter nodatacow. Il sera appliqué à tous les fichiers nouvellement créés.

Mais que se passe-t-il si nous voulons utiliser CoW lors de la copie par défaut?


  1. La manière radicale est de patcher les coreutils. Créez peut-être votre package dans votre référentiel privé.

    Patch du fichier cp.c :

     -x->reflink_mode = REFLINK_NEVER; +x->reflink_mode = REFLINK_AUTO;
  2. Une solution moins radicale consiste à écrire un alias cp pour votre shell. Pour bash, par exemple:

    Dans le dossier /etc/profile.d , créez un cp_reflink.sh cp_reflink.sh avec le contenu:

     #!/bin/bash alias cp='cp --reflink=auto'

    Cette solution fonctionnera dans presque tous les cas lorsque cp est accessible à partir d'un shell par son nom. Mais si / bin / cp sera utilisé dans les scripts, l'alias ne fonctionnera pas et la copie se fera comme d'habitude.

Gestionnaires de fichiers et reflink


Situation au 31 octobre 2019:

  • Midnight Commander - prend en charge.
  • Krusader - ne prend pas en charge.
  • Dolphin - ne prend pas en charge.
  • Nautilus - ne prend pas en charge.
  • Nemo - Supports.

Langages de programmation, appels système et reflink


La plupart des langages de programmation ne prennent pas en charge le reflink.
En C, de nombreux programmeurs copient toujours à l' aide de boucles et de tampons .

L'appel système sendfile n'utilise pas de reflink.
cp utilise l' appel système ioctl avec l'indicateur FICLONE.

Je pense que si vous avez besoin de copier quelque chose dans le code, il est conseillé de le faire comme le fait cp ou d'appeler simplement cp --reflink=auto .

Conclusions


Avec l'avènement de l'ère de la virtualisation omniprésente et du SSD, il est devenu très important d'utiliser les systèmes de fichiers CoW. Ils sont pratiques pour créer des instantanés, une copie rapide. En fait, lors de l'utilisation de CoW lors de la copie, nous effectuons automatiquement la déduplication des données .

Actuellement, seuls 3 systèmes de fichiers prennent en charge ce type de copie: BTRFS, XFS et OCFS2.

J'espère sincèrement que le support de refink sera complété dans ZFS et NILFS2, car ils supportent déjà CoW par des mécanismes internes.

Cependant, dans toutes les distributions Linux, CoW est désactivé lors de la copie de fichiers, et nous devons soit spécifier explicitement les clés correspondantes, soit utiliser diverses astuces telles que des alias ou des correctifs.

18 ans se sont écoulés depuis l'annonce de Reiser4, cependant, jusqu'à présent, la copie légère CoW n'est pas entrée dans notre vie partout.

PS Docker et CoW


Savez-vous que Docker prend en charge btrfs pour son stockage? Cette option doit être activée. Il n'est pas sélectionné par défaut.

Le système de fichiers CoW est en théorie le complément parfait d'une virtualisation facile lorsque différentes machines virtuelles utilisent le même noyau.

À mon avis, il est beaucoup plus organique que OverlayFS et Aufs, qui sont des béquilles technologiques pour simuler CoW.

Pour utiliser Btrfs dans Docker, vous avez besoin de:

  1. Dans une nouvelle installation (sans images ni machines virtuelles) de Docker, montez un volume Btrfs distinct sur /var/lib/docker
  2. Ajouter des options au fichier de configuration de lancement Docker

Pour Gentoo et calculer Linux, c'est /etc/conf.d/docker

 DOCKER_OPTS="--storage-driver btrfs --data-root /var/lib/docker"

Et voici les instructions complètes pour toutes les distributions.

Ajouts de commentaires


XFS et CoW


constb ( source ): Sur XFS, CoW n'est pas toujours pris en charge. Vous devez créer un système de fichiers avec mkfs.xfs -m reflink=1 .
Déjà sur le FS créé, vous ne pouvez pas «activer» le support CoW. de plus, sur les noyaux jusqu'à 4.11, l'inclusion de cette option provoque des avertissements rouges dans dmesg que la fonctionnalité est expérimentale.

MacOS et CoW


MMik ( source ): sous OS X, une option similaire à la commande cp est -c .

Cela implique l'utilisation de l'appel du système atomique clonefile() , qui crée une entrée dans le système de fichiers sur un nouveau fichier dans lequel les références aux blocs de données sont identiques à l'original. Les attributs et les attributs étendus du fichier sont copiés, les entrées de la liste de contrôle d'accès (ACL), à l'exception des informations sur le propriétaire du fichier et avec la réinitialisation des bits setuid / setgid. Il fonctionne dans le même système de fichiers, nécessite une prise en charge par le système de fichiers (attribut ATTR_VOL_CAPABILITIES, indicateur VOL_CAP_INT_CLONE).

Pris en charge depuis OS X 10.12 (Sierra) et uniquement sur le système de fichiers APFS .

Remerciements:


PPS Dirige les erreurs constatées dans un cadre personnel. J'augmente le karma pour cela.


Vous pouvez expérimenter avec les systèmes de fichiers CoW en commandant une machine virtuelle auprès de RUVDS avec le coupon ci-dessous.

Source: https://habr.com/ru/post/fr473752/

More articles:


All Articles