renommer un énorme dossier: est-ce risqué?

19

Est-il risqué de renommer un dossier de 180 Go avec la mvcommande?

Nous avons un dossier /dataqui contient 180 Go.

Nous voulons renommer le /datadossier /BD_FILESavec la mvcommande.

Est-ce sûr de faire ça?

linux filesystems mv Yael
la source
14
Pourquoi et comment cela devrait-il être risqué? Si vous n'êtes pas sûr, appelez mvavec l' -ioption.
dessert du
5
Y a-t-il quelque chose dans votre environnement qui vous fait penser que cela pourrait être risqué?
Jeff Schaller
2
Voulez-vous dire s'il y a un risque que la loi en soi puisse causer un problème, ou s'il y a un risque qu'il y ait des effets problématiques? Si vous avez des programmes qui s'attendent à ce qu'il y ait un dossier / data, le renommer pourrait causer des problèmes.
Accumulation
3
Remarque: Presque tout est sûr si vous avez vérifié les sauvegardes. Si vous ne le faites pas, rien n'est aussi sûr qu'il devrait l'être. En d'autres termes: lorsque vous demandez "est-ce sûr", votre première pensée devrait être "ai-je vérifié mes sauvegardes?"
RedGrittyBrick
2
Je veux dire que le risque qui pourrait être problématique lors du déplacement d'un énorme dossier avec des données par cet OS pourrait arrêter le déplacement au milieu par exemple ou des données lâches
yael

Réponses:

71

La modification du nom d'un dossier est sûre s'il reste dans le même système de fichiers.

S'il s'agit d'un point de montage (il /datasemble que ce pourrait être un point de montage pour moi, vérifiez cela avec mount), vous devez faire autre chose qu'un simple mvcar mv /data /BD_FILEScela déplacerait les données vers la partition racine (ce qui n'est peut-être pas ce que vous voulez arriver).

Vous devez démonter le système de fichiers, renommer le répertoire désormais vide, mettre /etc/fstabà jour avec le nouvel emplacement de ce système de fichiers, puis remonter le système de fichiers à l'emplacement renommé.

En d'autres termes,

  1. umount /data
  2. mv /data /BD_FILES(en supposant qu'il /BD_FILESn'existe pas déjà, dans ce cas, déplacez-le d'abord)
  3. mise à jour /etc/fstab, modification du point de montage de /dataà/BD_FILES
  4. mount /BD_FILES

Cela n'implique pas de copier des fichiers, il modifie simplement le nom du répertoire qui sert de point de montage pour le système de fichiers.

Si le changement de nom du répertoire implique de le déplacer vers un nouveau système de fichiers (ce qui serait le cas s'il se /datatrouve sur un disque alors qu'il se /BD_FILEStrouve sur un autre disque, une chose courante à faire si vous déplacez des choses vers une plus grande partition, par exemple) , Je vous recommande de copier les données tout en laissant l'original intact jusqu'à ce que vous puissiez vérifier que la copie est correcte. Vous pouvez le faire avec

rsync -a /data/ /BD_FILES/

par exemple, mais voir le rsyncmanuel pour ce que cela fait et ne fait pas (il ne préserve pas les liens durs, par exemple).

Une fois le dossier renommé, vous devez également vous assurer que les procédures existantes (programmes et utilisateurs utilisant le dossier, sauvegardes, etc.) sont au courant du changement de nom.

Kusalananda
la source
9
Il y a le risque que l'on s'attende mvà ne faire qu'un renameappel système, mais en raison de circonstances, on ne s'est pas rendu compte qu'il va copier les fichiers et supprimer l'original. Si je dois être absolument certain qu'un simple renameappel système est effectué et mvne va pas faire quelque chose de "intelligent" derrière mon dos, j'ouvre un shell Python et j'utilise os.rename.
kasperd
3
Avec un noyau Linux relativement récent, vous pouvez déplacer le point de montage à la place:mkdir /BD_FILES && mount -M /data /BD_FILES && rmdir /data
David Foerster
2
@MichealJohnson Cela fonctionnera probablement sur un système Linux, oui. La bonne chose avec, rsyncc'est qu'il est redémarrable.
Kusalananda
3
@MichealJohnson On utilise évidemment les outils que l'on est le plus à l'aise d'utiliser. Oui, rsync -apréserve presque toutes les métadonnées, mais pas les liens durs, les ACL ou les attributs étendus (ajoutez -HAXpour cela).
Kusalananda
3
@Max Différentes distributions ont des renamecommandes différentes avec un comportement différent. Je pense que c'est une raison suffisante pour ne pas utiliser la renamecommande lorsque vous voulez être certain de ce qu'elle va faire.
kasperd
16

Vous ne renommez pas tous les fichiers du répertoire, vous renommez un fichier dans /. C'est parce que:

  1. les répertoires sont des fichiers, et
  2. le système de fichiers se soucie vraiment de l'inode, pas du texte réel.

Ainsi, renommer un répertoire, quel que soit le nombre de fichiers ou la quantité de données qu'il contient, est trivial.

RonJohn
la source
14

Si vous renommez simplement (source et cible dans le même système de fichiers), il s'agit simplement d'un renommage d'une entrée de répertoire. Il réussit et le répertoire a un nouveau nom, ou échoue, auquel cas rien ne change * .

Si la source et la cible se trouvent sur des systèmes de fichiers différents, les données doivent être copiées par mv. Des différences dans les fonctionnalités du système de fichiers, telles que la taille maximale du fichier, les limitations des noms de fichier, etc., peuvent provoquer des problèmes. Pour éviter les problèmes, d' abord copier des fichiers ( cp, rsync, ...) et après la copie terminée, supprimer les fichiers dans l'emplacement d' origine.

* Cependant, il y a des cas d'angle, par exemple mentionnés dans la section BUGS dans man 2 rename

sebasth
la source
> "Il réussit et le répertoire a un nouveau nom, ou échoue, auquel cas rien ne change". Comment est-ce garanti? Est-ce vrai pour tous les systèmes de fichiers? Existe-t-il une documentation à ce sujet?
turbanoff
Renommer est un appel système unique, mais il y a une note sur NFS dans la section BUGS de man rename : le renommage peut être réussi même si une erreur est renvoyée lors de l'utilisation de NFS (voir les détails dans la page de manuel). J'ai également ajouté une note dans la réponse. Je ne m'attends pas à ce qu'un système de fichiers dans le noyau le considère acceptable pour une entrée de répertoire disparaître si un changement de nom échoue.
sebasth
8

Comme d'autres l'ont dit, renommer un dossier ne présente aucun risque inhérent au contenu. Mais il existe un autre type de risque que vous voudrez peut-être considérer.

Les procédures existantes, les scripts, les raccourcis définis par l'utilisateur et les configurations qui font référence à l'emplacement d'origine pourraient être rompus par cette modification, et si les chemins sont stockés dans une base de données, par exemple, leur mise à jour pourrait être un gros travail.

Une chose que vous pouvez faire est de créer un lien symbolique pour le nouveau nom de répertoire, mais laissez l'ancien nom en place pendant un certain temps. Cela vous donnera le temps d'évaluer l'impact de ce changement. Vous pouvez supprimer temporairement l'ancien nom, voir s'il y a des problèmes, et s'il y en a, recréez simplement l'ancien nom pour que les gens puissent continuer à travailler pendant que vous déterminez ce qui doit être mis à jour.

Une commande comme celle-ci devrait le faire: ln -s /data /BD_FILES

barbecue
la source
4
Un autre risque léger que personne n'a encore mentionné est que, selon votre stratégie de sauvegarde pour ce dossier, cela peut entraîner des problèmes d'espace disque et de latence sur le lecteur de sauvegarde en raison de 180 Go de «nouvelles» données apparaissant soudainement et nécessitant de être sauvegardé.
Kent
Je préfère quelque chose comme mv thing1 thing2 ; ln --symbolic ./thing2 thing1. De cette façon, j'ai le nouveau nom et je peux facilement tester l'absence de l'ancien en supprimant le lien symbolique.
can-ned_food
3

Renommer est atomique. Le seul risque raisonnable est celui qui mvdécide de tout copier pour une raison quelconque et qui se bloque à mi-chemin. Si vous avez GNU mv, mv -Tsupprimera ce risque.

mv -Tindique mvqu'il se déplace vers un non-dossier; ce qui l'amènera à refuser de le faire, mkdir()ce qui, à son tour, entraînera son échec en déplaçant un dossier et il a décidé de copier pour une raison quelconque.

J'ai participé à l'élimination des bogues pendant mv -Tque je travaillais sur la thèse de mon maître il y a des années. Il faisait la mauvaise chose sur trop de cas marginaux.

D'un autre côté, vous disposez de 180 Go de données utilisateur sur la partition racine. Vous souhaiterez probablement supprimer cela de la partition racine.

Joshua
la source
Vous ne pouvez pas dire à partir du nom seul si quelque chose est dans la "partition racine" ou non.
Peter
@Peter: Si ce n'est pas sur la partition racine, c'est un point de montage. Vous ne pouvez pas renommer les points de montage montés avec la commande mv.
Joshua