Fonds Linux
  1. Fonds Linux
  3. Pourquoi la paresse MNT_DETACH ou `umount -l` est-elle dangereuse / dangereuse?
Intereting Posts
Dans quel directory dois-je installer des programmes sous Linux? Comment countr le nombre de caractères d'une ligne, à l'exception d'un caractère spécifique? Créer un directory pour chaque ligne dans le file text donné? Comment append une string à un file .txt dans toutes les lignes en excluant quelques caractères en utilisant sed ou awk grep et queue -f? Comment accéder à nm-connection-editor à partir de l'interface graphique de GNOME 3? Comment tester si un élément est dans un tableau bash? Solaris: trouvez le jour de lundi dernier, mardi, … dimanche au moyen de script shell quel niveau de la stack réseau tcpdump obtient-il de ses informations? Activité suspecte de Crontab Comment m'assurer qu'un script est exécuté exclusivement? Comment créer un script qui bascule une valeur dans synclient? Reconfigurez la connection via la racine ftp (access ssh perdu) Comment faire un dialog de progression pour Bash dans XFCE? Étalonner l'écran LCD dans un ordinateur portable?

Pourquoi la paresse MNT_DETACH ou `umount -l` est-elle dangereuse / dangereuse?

J'ai lu dans quelques endroits que umount -l est dangereux:

Dans une réponse de @cas :

n'utilisez pas l'option --lazy umount si vous vous souciez du moment où le lecteur externe peut être débranché en toute security

Un commentaire de @frostschutz :

umount --lazy n'est pas sûr et ne peut pas être sécurisé. […]

Ce commentaire util-linux de Ruediger Meier :

Vous devriez éviter d'utiliser umount -l du tout. Il suffit de tuer tous les process qui utilisent /tmp/mountpoint , puis montez sans l'option -l .

Pourquoi umount -l dangereux / dangereux?

Y a-t-il un moyen de le rendre sécuritaire?

    Un déassembly paresseux crée une monture de chat de Schrödinger

    • Vous ne pouvez pas savoir si le périphérique est réellement démonté ou non
    • Le système de files "non monté" rest accessible dans certaines circonstances
    • Le système de files "non monté" n'est pas accessible dans certaines circonstances

    Il y a un faux sentiment de security : il semble que le système de files a été démonté, mais en réalité, il n'a été caché que dans l'espace de noms / hiérarchie du file.

    • Les process peuvent toujours écrire via des descripteurs de files ouverts
    • Les files nouveaux ou existants peuvent être ouverts pour l'écriture par des process avec un directory de travail à l'intérieur du sharepoint assembly via des paths relatifs

    Cela signifie que si vous umount -l /media/hdd vous ne pourrez plus accéder à /media/hdd/dir/file (nom de path absolu), mais si vous avez un process avec le directory de travail /media/hdd pour créer de nouveaux process qui peuvent lire / écrire ./dir/file (path relatif).

    Si vous tentez de démonter l'appareil, vous obtiendrez un message déroutant: 

     # umount --force --all-targets /dev/sdb2 umount: /dev/sdb2: not mounted

    Cela donne l'printing que l'appareil n'a pas été monté, mais il peut toujours y avoir des process d'écriture sur le disque.

    Comme il existe diverses situations non évidentes pouvant causer le blocage de umount , le système de files peut ne pas être démonté même si lsof +f -- /dev/device ne montre rien.

    Vous ne saurez jamais si le système de files se démonte réellement. Il n'y a aucun moyen de le savoir.

    Périphériques amovibles

    Si vous ne umount -l un disque amovible, vous êtes dans une impasse: vous ne pouvez pas être sûr que toutes datatables en attente ont été écrites sur le disque.

    Le mieux que vous puissiez faire après un umount -l est de s'assurer que toutes les écritures sont terminées et d'éviter d'écrire à l'avenir , mais vous ne pouvez toujours pas garantir qu'il a été démonté.

    Avec des périphériques amovibles, si le périphérique n'est pas démonté correctement, un comportement étrange peut se produire la prochaine fois qu'il est branché:

    • Le périphérique recevra un nom de périphérique incrémenté, par exemple /dev/sdb devient /dev/sdc . Les messages du journal du kernel peuvent toujours se référer à /dev/sdb même si ce périphérique n'existe plus en tant que file sous /dev . (La seule façon que je sache pour résoudre ce problème est de redémarrer.)

      • La corruption de btrfs peut en résulter. btrfs s'attend à ce qu'un seul système de files avec un UUID donné soit présent à la fois. Le kernel voit toujours le même UUID disponible sur le périphérique fantôme et le nouveau périphérique. (J'ai dû rebuild mon disque dur de sauvegarde btrfs)