Different filesystem counts between mount(8) and lsvfs(1)
Aaron LI
aly at aaronly.me
Fri Jun 8 08:29:07 PDT 2018
On Fri, 8 Jun 2018 07:40:01 -0700, Tim Darby <t+dfbsd at timdarby.net> wrote:
>
> Thanks for the initrd work. Can you also take a look at this possibly
> related bug:
> http://bugs.dragonflybsd.org/issues/2926
Hi Tim,
The getfsstat() count problem as you reported can be seen from the different
counts shown by mount(8) and lsvfs(1), and the main reason is due to the
chroot from the initrd temporary root into the real root, as Matt replied to
your email [1].
For example, on my box (encrypted root and chrooted from initrd):
-------------------------------------------------------------------
# mount
/dev/mapper/root at DATA on / (hammer2, local)
/dev on /dev (null, local)
/dev/vbd0s1a on /boot (ufs, local)
/build/usr.obj on /usr/obj (null)
/build/var.crash on /var/crash (null)
/build/var.cache on /var/cache (null)
/build/var.spool on /var/spool (null)
/build/var.log on /var/log (null)
/build/var.tmp on /var/tmp (null)
procfs on /proc (procfs, local)
-------------------------------------------------------------------
# lsvfs
Filesystem Num Refs Flags
-------------------------------- ---------- ----- ---------------
nfs 0x00000001 0 network
msdos 0x00000002 0
cd9660 0x00000003 0 read-only
devfs 0x00000004 2 synthetic
ufs 0x00000005 2
procfs 0x00000006 1 synthetic
hammer 0x00000007 0
tmpfs 0x00000008 1
mfs 0x00000009 0
null 0x0000000a 7 loopback
hammer2 0x0000000b 1
-------------------------------------------------------------------
So lsvfs(1) gives: 1 more tmpfs, 1 more ufs, and 2 more devfs. I observed
this mismatch sometime before, and discussed with Sascha Wildner. But we can
only explain 3 of the 4 more filesystems:
* 1 tmpfs: mount of the initrd image (it's a memory disk)
* 1 ufs: the temporary root (UFS) mounted from the initrd image (Sascha
already updated the lsvfs.1 man page about this)
* 1 devfs: the actually devfs is mounted at /dev of the temporary root, which
is then null-mounted to /new_root/dev, as you can see from mount(8):
"/dev on /dev (null, local)".
But there still remains 1 mysterious devfs... anyone have more ideas?
[1] http://lists.dragonflybsd.org/pipermail/users/2016-July/334756.html
Cheers,
--
Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20180608/39d1883b/attachment.bin>
More information about the Users
mailing list