The manpage /proc/pid/mountinfo said it has the field

36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue

(1)(2)(3)   (4)   (5)      (6)      (7)   (8) (9)   (10)         (11)

(10) mount source: filesystem-specific information or "none".

What does this field (10) mean exactly? I got weird result from my own experiment

279 23 7:0 /file//deleted /home/xtricman/file_mnt_point rw,relatime shared:158 - ext4 /dev/loop0 rw
301 23 7:0 /file2//deleted /home/xtricman/file_mnt_point2 rw,relatime shared:158 - ext4 /dev/loop0 rw
268 23 7:0 / /mnt rw,relatime shared:159 - ext4 /dev/loop0 rw
313 23 7:0 / /home/xtricman/home_mnt rw,relatime shared:183 - ext4 /home/xtricman/loop1 rw

/dev/loop0 is created automatically by mount program when I do mount a.ext4 /mnt, and /home/xtricman/loop1 is created manually by mknod loop1 b 7 0.

So I guess I can explain most of the results I see, but why does the device node path appear in the (10) field? I'm using Linux 5.0.4 kernel on ArchLinux, if that matters.


What does this field (10) mean exactly?

It's either the first argument (source) as it was passed to the mount(2) system call, or some filesystem specific info returned by the show_devname() callback, if the filesystem implements it.

The (7) is actually a list of optional fields which may not be present, so (10) may be actually (9).

/dev/loop0 is created automatically by mount when I do mount a.ext4 /mnt, and /home/xtricman/loop1 is created manually by mknod loop1 b 7 0.

/dev/loop0 is not "created automatically" when you use the mount(2) system call.

It's the mount(8) utility which, when called with a "device" argument which is a regular file (and using some DWIM guessing) will first find a free loop device, attach it to the file given as argument, and call mount(2) with the path to the loop device and the mount point as arguments.


# strace -e trace=ioctl,mount mount /tmp/foo $'/tmp/foox\tX\nX\\X X'
ioctl(3, LOOP_CTL_GET_FREE)             = 0
ioctl(4, LOOP_SET_FD, 3)                = 0
ioctl(4, LOOP_SET_STATUS64, {lo_offset=0, lo_number=0, lo_flags=LO_FLAGS_AUTOCLEAR, lo_file_name="/tmp/foo", ...}) = 0
ioctl(3, BLKGETSIZE64, [536870912])     = 0
ioctl(3, CDROM_GET_CAPABILITY, 0)       = -1 EINVAL (Invalid argument)
ioctl(3, BLKSSZGET, [512])              = 0
mount("/dev/loop0", "/tmp/foox\tX\nX\\X X", "btrfs", MS_MGC_VAL, NULL) = 0
| improve this answer | |
  • (7) usually being absent depends on your OS. Or at least, when the OS uses systemd, it will usually consist of exactly one field, shared:<id>. – sourcejedi Apr 24 '19 at 7:48
  • I know it's created by the program not the syscall. But field (7) doesn't seem to be systemd related according to the man page or the kernel code you give, (7) seems always to be the propagation type of the mount. – 炸鱼薯条德里克 Apr 24 '19 at 11:23
  • did I say anything about systemd? – mosvy Apr 24 '19 at 12:46
  • @炸鱼薯条德里克 systemd sets shared propagation on most mounts. mosvy originally said (7) is usually not present, I guessed because they have looked at mountinfo on some machine that did not use systemd, or they did not look and were not aware that systemd sets up shared mounts by default. – sourcejedi Apr 24 '19 at 12:54
  • @sourcejedi I know that systemd sets shared propagation by default. I wasn't aware of how much that stupid idea already propagated in the embedded world. – mosvy Apr 24 '19 at 13:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.