Déterminez le périphérique sur lequel se trouve un directory

Si je fais

# cd / # ln -s /home test # cd test # mount --bind $PWD /mnt 

l'input dans /proc/mounts est

 /dev/sda2 /mnt ext4 rw,noatime,data=ordered 0 0 

qui est le périphérique monté sur /home et qui n'est pas facilement déductible à partir de $PWD qui est /test . Comment puis-je déterminer quel périphérique (par exemple, / dev / sda2) va apparaître dans /proc/mounts en général étant donné que la binding bind peut être un directory / file potentiellement "obscurci" par des liens symboliques , etc?

    Si je comprends votre question, vous voulez savoir quel périphérique a été utilisé pour une monture donnée. Pour cela, vous pouvez utiliser la command df :

     $ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/fedora_greeneggs-root 50G 21G 27G 44% / devtmpfs 3.8G 0 3.8G 0% /dev tmpfs 3.8G 14M 3.8G 1% /dev/shm tmpfs 3.8G 984K 3.8G 1% /run tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup tmpfs 3.8G 3.4M 3.8G 1% /tmp /dev/sda1 477M 99M 349M 23% /boot /dev/mapper/fedora_greeneggs-home 402G 184G 198G 49% /home 

    Pour find quel périphérique un file / directory particulier est trouvé, donnez le file en argument à df . En utilisant votre exemple:

     $ df -h /mnt Filesystem Size Used Avail Use% Mounted on /dev/sda1 477M 99M 349M 23% / 

    Vous pouvez également utiliser la command mount :

     $ mount | grep '^/dev' /dev/mapper/fedora_greeneggs-root on / type ext4 (rw,relatime,seclabel,data=ordered) /dev/sda1 on /boot type ext4 (rw,relatime,seclabel,data=ordered) /dev/mapper/fedora_greeneggs-home on /home type ext4 (rw,relatime,seclabel,data=ordered) 

    Le directory monté pour chaque périphérique est le 3ème argument de la sortie ci-dessus. Donc, pour le périphérique /dev/sda1 serait /boot . Les autres appareils utilisent LVM (Logical Volume Management) et devraient être interrogés pour savoir quel appareil est utilisé par LVM.

    La méthode la plus précise dont je suis conscient est d'utiliser la sortie de l'appel système lstat (). Spécifiquement, le champ st_dev. Il y a un utilitaire de command line, stat (1) qui peut être utilisé pour voir cette information. Par exemple, la sortie de "stat / etc / issue" sur mon ordinateur portable:

     File: '/etc/issue' Size: 65 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 1610916043 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) 

    Notez la troisième ligne, premier champ, "Device". Ici, il répertorie 801h. Cette valeur peut être séparée en deux octets, 8 et 1. Le premier octet est appelé le numéro principal, le deuxième octet est le numéro mineur. Donc, la prochaine étape est de déterminer quel appareil majeur 8, mineur 1 est.

    Je trouve que consulting / proc / partitions est le plus rapide. Dans mon cas, / proc / partitions a le contenu:

     major minor #blocks name 8 16 234431064 sdb 8 17 33554432 sdb1 8 18 200875608 sdb2 8 0 500107608 sda 8 1 500106584 sda1 

    Il est plutôt clair à partir de cette sortie que major 8, minor 1 est sda1. Nous pouvons le confirmer avec un ls -l / dev / sda1

     brw-rw---- 1 root disk 8, 1 May 8 05:33 /dev/sda1 

    Notez le 8, 1 avant l'horodatage.

    Il est important de comprendre / se callbacker que le nom d'un file de périphérique tel que / dev / sda1 n'est qu'une label. Les numéros majeurs et mineurs sont les valeurs importantes et importantes du file de périphérique. Si vous êtes curieux, consultez l'utilitaire mknod (1) utilisé pour créer des files de périphériques. Je pourrais créer une nouvelle input / dev appelée aardvark avec majeure 8, minor 18 avec la syntaxe suivante:

     mknod /dev/aardvark b 8 18 

    Ensuite, je pourrais facilement le monter:

     mount /dev/aardvark /mnt 

    et, si nous regardons la sortie de la command mount ou le contenu de / proc / monts et nous voyons:

     /dev/aardvark on /mnt type xfs (rw,relatime,attr2,inode64,noquota) 

    df -h montre:

     /dev/aardvark 192G 154G 38G 81% /mnt 

    … Quoi qu'il en soit, le but de tout ceci est d'illustrer que les détails importants pour identifier un périphérique en bloc sont les numéros majeurs et mineurs – pas l'label du file de périphérique – et que l'utilisation de l'appel système lstat () est la meilleure façon de interroge ces valeurs.

    Comme dernier commentaire, je relis juste votre question pour m'assurer d'y répondre et j'ai réalisé que vous demandiez quelle label de périphérique source apparaîtrait dans / proc / montures pour un assembly de bind. Ce serait la même label de périphérique source que celle utilisée dans l'appel d'origine mount (2) pour la source de sharepoint assembly du système de files pour le assembly bind. Peut-être qu'un exemple pourrait aider:

    J'ai / dev / sdb2 et / dev / aardvark (le même que ci-dessus). Ils sont à la fois majeurs 8, mineurs 18. Note, je vais monter le même système de files deux fois. Je fais ce qui suit:

     mkdir /mnt1 /mnt2 /foo mount /dev/aardvark /mnt1 mount /dev/sdb2 /mnt2 

    Notez que je fais le directory somedir dans / mnt1. Mais puisque / mnt1 et / mnt2 ont le même système de files monté, somedir sera également accessible via / mnt2.

     mkdir /mnt1/somedir mkdir /foo/left /foo/right mount -o bind /mnt1/somedir /foo/left mount -o bind /mnt2/somedir /foo/right 

    Maintenant, si nous vérifions / proc / monte, nous voyons:

     /dev/aardvark /mnt1 xfs rw,relatime,attr2,inode64,noquota 0 0 /dev/sdb2 /mnt2 xfs rw,relatime,attr2,inode64,noquota 0 0 /dev/aardvark /foo/left xfs rw,relatime,attr2,inode64,noquota 0 0 /dev/sdb2 /foo/right xfs rw,relatime,attr2,inode64,noquota 0 0 

    L'label du périphérique source sur / foo / … bind mount est la même que la valeur initialement fournie dans l'appel mountyst (2) du système de files. Rappelez-vous, / dev / aardvark et / dev / sdb2 dans mon exemple sont le même périphérique.

    Je me rends count que je viens de dactylographier un roman et la première moitié ne répond pas vraiment à votre question, mais il semblait comme un gaspillage de le supprimer. Peut-être que cela aidera quelqu'un d'autre.

    Bonne chance.

    PS N'oubliez pas que certains filesystems sont basés sur le réseau – comme NFS ou CIFS – ou sont virtuels – comme procfs ou sysfs et n'ont pas de périphérique source. Je ne sais pas ce qui sera returnné comme l'appareil dans la sortie stat, juste fwiw.

    Sur Linux, nous avons findmnt d' util-linux exactement fait pour cela

     findmnt -n -o SOURCE --target /path/to/FILE 

    L'avantage d'autres solutions est qu'il fonctionne toujours si les paths sont obscurcis par des liens symboliques ou des assemblys de binding en double.

    Compte tenu des points de assembly typiques suivants:

     $ df --output=target Mounted on / /dev /run /sys/fs/cgroup /run/lock /run/shm /run/user 

    stat --format %m <path> n'imprimera que le sharepoint assembly d'une manière round-trappable (bien que vous ayez besoin de vérifier le code de sortie pour détecter sans ambiguïté une erreur d'autorisation;

     $ stat --format %m / / $ stat --format %m /tmp / $ stat --format %m /proc /proc $ stat --format %m /run /run $ stat --format %m /run/mount /run $ stat --format %m /run/user /run/user $ stat --format %m /run/user/1000/dconf /run/user $ stat --format %m /run/user/1000/gvfs /run/user/1000/gvfs 

    Symlinks prend un peu de soin comme d'habitude:

     $ ls -lh ~/.gvfs /home/cwillu/.gvfs -> /run/user/1000/gvfs $ stat --format %m ~/.gvfs /run/user/1000/gvfs $ stat --format %m ~/.gvfs / 

    Et bien sûr, n'oubliez pas d'utiliser des guillemets pour les scripts. Considérons un path de assembly avec des espaces et tels:

     $ mkdir /tmp/Something\ Like\ This\! $ sudo mount none /tmp/Something\ Like\ This\! -t tmpfs $ stat --format %m /tmp/Something\ Like\ This\! /tmp/Something Like This! $ touch /tmp/Something\ Like\ This\!/pretend-I\'m-big $ ls /tmp/Something\ Like\ This\! pretend-I'm-big 

    Quelle est votre taille?

     $ du $(stat --format %m /tmp/Something\ Like\ This\!/) du: cannot access /tmp/Something: No such file or directory du: cannot access Like: No such file or directory du: cannot access This!: No such file or directory $ du "$(stat --format %m /tmp/Something\ Like\ This\!/)" 0 /tmp/Something Like This! 

    La complétion de l'onglet de ma distro ne l'est même pas, donc nous allons utiliser cet exemple de sharepoint assembly avec des returns chariot, des returns à la ligne et des espaces:

     $ stat --format %m /tmp/Something* /tmp/Something Like This! $ a="$(stat --format %m /tmp/Something*)" # the above assignment is actually the one place you don't need quotes, # but `export a=...` or similar _would_ need them, so we'll just put them in; # they don't change the behaviour in this form of assignment. $ stat "$a" File: '/tmp/Something \r\n\rLike This!' Size: 40 Blocks: 0 IO Block: 4096 directory Device: 7bh/123d Inode: 1279171 Links: 2 Access: (1777/drwxrwxrwt) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2016-09-30 11:43:17.933467344 -0600 Modify: 2016-09-30 11:43:17.933467344 -0600 Change: 2016-09-30 11:43:17.933467344 -0600 Birth: -