Pourquoi cp --reflink = auto n'est-il pas le comportement par défaut?

31

Pourquoi ce n'est cp --reflink=autopas le comportement par défaut? Cela pourrait-il nuire à son activation?

Est-il possible de l'activer au moment de la compilation, afin qu'il soit utilisé dans tout le système, pas seulement dans des shells interactifs?

btrfs coreutils

— Fabian Henze
source

4

Oui, bonne question. À mon humble avis, comme seul BTRFS commence à être un système de fichiers Linux par défaut.

— Adam Ryczkowski

38

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.

— Pádraig Brady
source

8

(cela pourrait être considéré comme une réponse faisant autorité puisque Pádraig est un mainteneur de GNU coreutils).

— Stéphane Chazelas

8

Je doute que cette réponse soit correcte, au moins sur btrfs. Si le fichier est écrit ultérieurement, les nouvelles données seront de toute façon écrites sur un secteur de disque différent en raison de CoW btrfs, il n'y a donc aucun avantage de latence à ne pas effectuer de reflinks. Les fichiers sur lesquels NoDataCoW est défini ne peuvent de toute façon pas être redéfinis. Et si vous souhaitez vous protéger contre la corruption des données, vous devrez copier sur une autre partition et les reflinks ne fonctionneront pas non plus.

— JanKanis, le

3

Il y a des problèmes de latence car BTRFS doit trouver et allouer de l'espace au moment de l'écriture. Cela pourrait même ne pas être disponible, générant ainsi des erreurs ENOSPC au moment de l'écriture

— Pádraig Brady

1

À quoi sert le MV pour le reflink?

— Macil

1

cross subvolume renames on btrfs

— Pádraig Brady

17

Je ne sais pas pourquoi ce n'est pas la valeur par défaut, peut - être pour qu'il se comporte de la même chose que d' autres utilitaires de copie ( rsync, cpio, pax, tar...) qui ne les supporte pas (ou lorsque les fichiers sont copiés dans une interface qui ne permet pas (comme NFS, samba, fusionner les couches des systèmes de fichiers ...).

J'étais dans la même situation il y a quelques années, et en regardant rapidement le code cp GNU, c'est toujours la même chose, vous devez patcher le code pour obtenir un comportement par défaut différent:

--- coreutils-8.21/src/cp.c~    2013-06-22 21:50:26.265639114 +0100
+++ coreutils-8.21/src/cp.c     2013-06-22 21:51:06.880513924 +0100
@@ -775,7 +775,7 @@ cp_option_init (struct cp_options *x)
   x->interactive = I_UNSPECIFIED;
   x->move_mode = false;
   x->one_file_system = false;
-  x->reflink_mode = REFLINK_NEVER;
+  x->reflink_mode = REFLINK_AUTO;

   x->preserve_ownership = false;
   x->preserve_links = false;

— Stéphane Chazelas
source

4

Un gros problème est le risque de manquer d'espace pour faire la copie lorsque vous écrivez.

Avec une copie normale, dès que la copie est terminée, vous n'avez jamais à vous soucier de l'échec d'une écriture dans des parties existantes du fichier: l'espace est entièrement alloué et ne disparaîtra pas tant que vous n'aurez pas supprimé le fichier. Mais avec une copie de refixation, il y a toujours un risque qu'à un moment donné des semaines ou des mois, une écriture dans une partie existante du fichier échoue car il n'y avait pas assez d'espace pour faire une copie.

Découvrir que votre système avait fait des copies de reflink derrière votre dos lorsqu'une opération comme celle-ci a échoué serait une très mauvaise surprise.

— gwd
source

Au moins sur btrfs, même écrire dans une partie déjà allouée du fichier peut échouer avec ENOSPC ...

— graywolf

2

alias cp='cp --reflink=auto --sparse=always'

est plus logique que de patcher le code

— Le blog technique de James
source

6

On dirait que vous avez ignoré Est-il possible de l'activer au moment de la compilation, donc il est utilisé partout dans le système, pas seulement dans des shells interactifs dans la question de l'OP.

— Stéphane Chazelas

5

@StephaneChazelas On pourrait toujours le renommer /bin/cpet le remplacer par un script shell similaire

— goncalopp

0

Des raisons de robustesse peuvent vouloir qu'une copie soit effectuée pour se protéger contre la «perte» de données.

Nous ne savons pas que c'est la raison, mais les mauvaises choses qui peuvent arriver se limitent à la destruction des médias. La plupart de tous les périphériques de bloc auront une forme d'identification de corruption (crc), sinon une correction d'erreur (parité).
Pas pour des raisons de performances.

CoW se produit lorsque seulement une partie de la? Effacer? le bloc est écrit. Avec le disque! Moderne! périphérique la taille du bloc matériel est un multiple de 4k. Changer une partie du 4k amène le lecteur à lire le 4k entier et à le réécrire, mais en plus de cela, le noyau va faire la même chose donc il n'y aura pas d'écritures partielles atteignant le périphérique de bloc, SSD ou autre . Le noyau doit effectuer le CoW pour les mêmes raisons, sauf si nous avons une copie en cache, nous ne pouvons pas créer les données qui existent dans les autres parties de l'appareil, sauf pour la fin du conte d'un fichier, mais le point est discutable. Mais la mise en cache d'une copie d'un fichier et la copie d'un fichier sont différentes opérations différentes, la première est beaucoup moins chère.

L'adresse de l'écriture est sans importance, mais faites savoir que "une partie inutilisée de l'appareil" est moins chère à découvrir que "où résident actuellement les blocs du fichier".

Le fait est que toute méthode CoW est moins chère ou équivalente à la simple mise à jour d'un périphérique bloc. Maintenant, si nous ne parlions pas de blocs, alors ce serait une autre histoire ... écrite quelque part sur bande.

— Mike Mestnik
source