1

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.

Hauke Laging
  • 88,146
  • 18
  • 125
  • 174
炸鱼薯条德里克
  • 1,337
  • 1
  • 12
  • 31

1 Answers1

2

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.

Example:

# 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
  • (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:`. – sourcejedi Apr 24 '19 at 07: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? –  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](https://unix.stackexchange.com/questions/502220/why-duplicate-mount-bind-cause-empty-dev-pts#comment925947_502220) that systemd sets shared propagation by default. I wasn't aware of how much that stupid idea already propagated in the embedded world. –  Apr 24 '19 at 13:09
  • @sourcejedi Just in case it wasn't clear, I was explicitly talking about shared propagation (it's also the default on android, for instance - and many other non-systemd linux systems). –  Apr 24 '19 at 14:46
  • Even without systemd, you can still make a shared/private/slave mount, causing the appearance of (7). The reason that (7) doesn't exist or has some value is the mount has a certain propagation type, not because of systemd. According to the manpage, it isn't possible to have other things than propagation type indicator at (7). @sourcejedi – 炸鱼薯条德里克 Apr 24 '19 at 16:43
  • @炸鱼薯条德里克 I was criticizing the statement "the (7) is actually a list of optional fields which are usually not present", in a [previous](https://unix.stackexchange.com/revisions/515164/4) version of this answer. This statement has been removed, and I make no further criticism. Hence my comment is eligible to be deleted. But I try not to self-delete a comment immediately after someone asks me about it :-). If you want to ask further questions, perhaps you could hit me up on the Chat site, since it would not be a direct comment about this answer. – sourcejedi Apr 24 '19 at 17:50