Risques liés à l'élimination des fusibles de Linux (pour se débarrasser des fichiers .fuse_hidden)

Réponse courte

La suppression du fuse entraînera probablement l'impossibilité de monter le système de fichiers.

FUSE est un système de fichiers dans l' espace utilisateur, ce qui signifie qu'il existe un programme d'espace utilisateur qui gère toutes les opérations effectuées sur ce système de fichiers spécifique (alors que le support de système de fichiers sans fusible fonctionne dans kernelspace). Il peut être ntfs-3g dans votre cas; Même si ce n'est pas le cas, l'histoire est généralement la même.

Toutes les implémentations spécifiques de FUSE dépendent du module de fuse et ntfs-3g fait partie d'eux (bien, formellement, c'est une pré-dépendance, mais cela ne change pas ici ). Cela signifie que vous ne pouvez pas supprimer le fuse et que ntfs-3g (ou un autre programme FUSE) fonctionne.

Ce qui vous dérange vraiment, c'est l'existence de fichiers .fuse_hidden (comparez: problème XY ). Le reste de ma réponse répond à ce problème.

---

Le contexte

Il semble que vous pouvez ignorer les fichiers .fuse_hidden , comme indiqué ici: Qu'est-ce .fuse_hidden fichier .fuse_hidden et pourquoi existent-ils?

La réponse à Comment supprimer les fichiers .fuse_hidden ? Compare le comportement FUSE à NFS:

Ceci est similaire à ce qui se produit lorsque vous supprimez un fichier qu'un autre système a ouvert sur une monture NFS.

Et le comportement NFS est expliqué ici . De là:

Que se passe-t-il lorsqu'un fichier est ouvert par un client et supprimé? Le fichier doit conserver son nom, afin que le client qui l'ait ouvert puisse y accéder. Mais lorsqu'un fichier est supprimé, il est prévu qu'il n'y ait plus de fichier par ce nom après. Ainsi, les serveurs NFS activent la suppression d'un fichier ouvert en renommant: le fichier est renommé à .nfs… ( .nfs suivi d'une chaîne de lettres et de chiffres).

C'est tout parce qu'un fichier sous Linux peut être supprimé alors qu'il est ouvert par un processus . Ce mécanisme fonctionne par conception avec des systèmes de fichiers locaux basés sur l'inode (comme la famille ext), mais il doit être émulé en quelque sorte si l'accès aux fichiers dépend uniquement de leurs noms. Je crois que la situation avec NTFS est quelque peu compliquée. Vous pouvez trouver des commentaires et des liens intéressants sous le lien ci-dessus.

Eh bien, ntfs-3g pourrait imiter le comportement général de Windows et nier l'élimination du fichier lorsqu'il est utilisé. Le problème est que de nombreux programmes Linux s'attendent à ce qu'ils puissent supprimer le fichier qu'ils utilisent encore. C'est assez intelligent.

Supposons que votre programme nécessite un fichier temporaire. Il en crée un, l'ouvre et supprime immédiatement – et Linux le permet. Désormais, la tâche consistant à libérer l'espace disque (lorsque le fichier n'est plus nécessaire) est le travail de quelqu'un d'autre: le noyau ou FUSE. Cette tâche sera traitée gracieusement, même si votre programme meurt de façon inattendue ou est tué avec force.

D'autre part, si votre programme ne peut pas supprimer le fichier au préalable, il est toujours utile de le nettoyer lorsqu'il est terminé; Une résiliation inattendue peut laisser le fichier temporaire «abandonné». Et si quelqu'un d'autre ouvrait le même fichier? Ensuite, votre programme ne peut pas l'enlever même s'il est fait et tout va bien.

Il est bon de conserver cette façon de gérer Linux les fichiers. Les fichiers comme .fuse_hidden ou .nfs sont le coût de cette philosophie et ils seront supprimés éventuellement. Mais disons que quelque chose a mal tourné et qu'ils ne le feront pas. Il est encore relativement facile de les repérer pendant la maintenance manuelle, alors que dans Windows, vous pouvez avoir des fichiers «abandonnés» et ne pas le savoir. La manière Linux me paraît une approche beaucoup plus pointilleuse.

---

Quelques tests

Mon banc d'essai:

 # whoami root # cat /etc/issue Ubuntu 16.04.2 LTS \n \l # uname -a Linux foobar 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux # dpkg -l | grep ntfs-3g ii ntfs-3g 1:2015.3.14AR.1-1ubuntu0.1 amd64 read/write NTFS driver for FUSE 

Préparation des points de montage:

 # mkdir /mnt/ext4 /mnt/ntfs 

Préparation des systèmes de fichiers:

 # truncate -s 20M image-ext4 # truncate -s 20M image-ntfs # mkfs.ext4 -Fq image-ext4 # mkfs.ntfs -FqQ image-ntfs 

(Sortie Chatty de mkfs.ntfs supprimé.)

Montage:

 # mount image-ext4 /mnt/ext4/ # mount image-ntfs /mnt/ntfs/ 

Utilisation initiale du disque:

 # df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 172K 17M 1% /mnt/ext4 /dev/loop1 20M 2.5M 18M 13% /mnt/ntfs 

Création de fichiers:

 # dd if=/dev/urandom bs=1M count=10 | tee /mnt/ext4/file > /mnt/ntfs/file 10+0 records in 10+0 records out 10485760 bytes (10 MB, 10 MiB) copied, 0.645865 s, 16.2 MB/s 

Utilisation du disque:

 # df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 11M 6.8M 60% /mnt/ext4 /dev/loop1 20M 13M 7.6M 63% /mnt/ntfs 

Ouvrir des fichiers, puis supprimer:

 # exec 3<> /mnt/ext4/file # exec 4<> /mnt/ntfs/file # rm /mnt/ext4/file /mnt/ntfs/file 

Utilisation du disque:

 # df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 11M 6.8M 60% /mnt/ext4 /dev/loop1 20M 13M 7.6M 63% /mnt/ntfs 

Donc, malgré le retrait, l'espace disque est toujours utilisé. C'est parce que les fichiers sont encore ouverts.

Fichiers actuels:

 # ls -A /mnt/ext4/ /mnt/ntfs/ /mnt/ext4/: lost+found /mnt/ntfs/: .fuse_hidden0000000200000001 

À ce stade, je fais des copies des systèmes de fichiers (pour une comparaison ultérieure). Je sais en général que je ne devrais pas faire cela pendant qu'ils sont montés, mais l'idée est de simuler la remise à neuf avant de fermer les fichiers. Pourtant, je veux que les systèmes de fichiers copiés soient propres, d'où la commande de sync . De plus, l'option --reflink=always me permet de faire des copies de type instantané sur mon système de fichiers Btrfs où image-ext4 et image-ntfs sont stockées; Dans ce test, les cp devraient également fonctionner.

 # sync # cp --reflink=always image-ext4 copy-ext4 # cp --reflink=always image-ntfs copy-ntfs 

Je peux vérifier si copy-ext4 est propre:

 # fsck.ext4 copy-ext4 e2fsck 1.42.13 (17-May-2015) copy-ext4: clean, 11/5136 files, 1849/20480 blocks 

Malheureusement, il n'y a pas de fsck.ntfs .

Continuons avec les systèmes de fichiers originaux. Fermeture des fichiers:

 # exec 3>&- # exec 4>&- 

Utilisation du disque:

 # df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 172K 17M 1% /mnt/ext4 /dev/loop1 20M 2.5M 18M 13% /mnt/ntfs 

Contenu:

 # ls -A /mnt/ext4/ /mnt/ntfs/ /mnt/ext4/: lost+found /mnt/ntfs/: 

Le fichier .fuse_hidden n'est plus et l'espace disque est à nouveau gratuit. Le fichier disparaît lorsqu'il n'est plus nécessaire.

Voyons ce qui se passe après la réinitialisation simulée, lorsque les fichiers n'ont pas été correctement fermés. Montage des copies:

 # umount /mnt/ext4 /mnt/ntfs # mount copy-ext4 /mnt/ext4/ # mount copy-ntfs /mnt/ntfs/ 

Utilisation du disque:

 # df -h /mnt/ext4/ /mnt/ntfs/ Filesystem Size Used Avail Use% Mounted on /dev/loop0 19M 172K 17M 1% /mnt/ext4 /dev/loop1 20M 13M 7.6M 63% /mnt/ntfs 

Fichiers actuels:

 # ls -A /mnt/ext4/ /mnt/ntfs/ /mnt/ext4/: lost+found /mnt/ntfs/: .fuse_hidden0000000200000001 

C'est donc un scénario lorsque vous devez supprimer manuellement les fichiers .fuse_hidden . Notez que si ntfs-3g n'a pas créé un tel fichier et a refusé le retrait en premier lieu, vous devriez maintenant avoir un fichier restant avec son ancien nom; Vous l'auriez même sans réinitialiser et cela signifie encore plus de maintenance.

Je crois que les systèmes de fichiers basés sur l'inode n'ont pas besoin d'une telle maintenance.

Nettoyage:

 # umount /mnt/ext4 /mnt/ntfs # rmdir /mnt/ext4/ /mnt/ntfs/ # rm image-ext4 copy-ext4 image-ntfs copy-ntfs