All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave T <davestechshop@gmail.com>
To: kreijack@inwind.it
Cc: devel@roosoft.ltd.uk,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	Phillip Susi <phill@thesusis.net>,
	kilobyte@angband.pl
Subject: Re: why is the same mount point repeatedly mounted in nested manner?
Date: Mon, 9 Aug 2021 16:15:36 -0400	[thread overview]
Message-ID: <CAGdWbB7KOzsWUEJWtKDfTD-hXOeh+Rhvk1iuXeRMjdqxVhA_uw@mail.gmail.com> (raw)
In-Reply-To: <6f133a41-dbd6-ce42-b6aa-ae4e621ce816@libero.it>

On Mon, Aug 9, 2021 at 3:29 PM Goffredo Baroncelli <kreijack@libero.it> wrote:
>
> On 8/8/21 9:48 PM, Dave T wrote:
> > On Sun, Aug 8, 2021 at 8:10 AM <devel@roosoft.ltd.uk> wrote:
> >>
> >> On 05/08/2021 17:46, Dave T wrote:
> [...]
> >>
> >> Try mounting the subvolume with it's subvolume ID. System only generates
> >> unit files from the fstab it does not follow them , so if you are vague
> >> in your fstab the systemd unit files will also be vague.
> >
> > Thank you for the tip. I appreciate your interest in my issue.
> > However, I don't fully understand what to change.
>
> I think that Alexander is suggesting to add something like ',subvolid=5' to the line of fstab where /mnt/btrtop/root is mounted.

I see. Thank you (and Alexander). I will add that! EDIT: I just added
it and tested mounting, umounting. It seems to work exactly the same
as previously. findmnt now reports:

├─/mnt/btrtop/root                       /dev/mapper/rootluks
                               btrfs
rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=5,subvol=/

>
> I add that if it is a systemd bug, it would help to look at the .mount files generated by systemd:
>
> $ sudo ls /run/systemd/generator/*.mount
>
> Can you share the content of the  systemd units where you ask to mount '/mnt/btrtop/root' ? It could help the diagnose.
>
Thank you. Good tip. I had not looked at those files before. Here are
the generator files (before my change to add ,subvolid=5).

# cat /run/systemd/generator/-.mount
# Automatically generated by systemd-fstab-generator
[Unit]
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
SourcePath=/etc/fstab
Before=local-fs.target
After=blockdev@dev-disk-by\x2duuid-28D099A\x2d49D92\x2d4487C\x2d48113\x2d4A231CAD0EEF2.target
[Mount]
Where=/
What=/dev/disk/by-uuid/28D099A-9D92-487C-8113-A231CAD0EEF2
Type=btrfs
Options=rw,noatime,nodiratime,compress=lzo,space_cache,subvol=/@btrtop/snapshot



# cat /run/systemd/generator/mnt-btrtop-root.mount
# Automatically generated by systemd-fstab-generator
[Unit]
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
SourcePath=/etc/fstab
After=blockdev@dev-disk-by\x2duuid-28D099A\x2d49D92\x2d4487C\x2d48113\x2d4A231CAD0EEF2.target
[Mount]
Where=/mnt/btrtop/root
What=/dev/disk/by-uuid/28D099A-9D92-487C-8113-A231CAD0EEF2
Type=btrfs
Options=noauto,nofail,rw,noatime,nodiratime,compress=lzo,space_cache




# cat /run/systemd/generator/srv-nfs-var-cache-pacman.mount
# Automatically generated by systemd-fstab-generator
[Unit]
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
SourcePath=/etc/fstab
Before=local-fs.target
[Mount]
Where=/srv/nfs/var/cache/pacman
What=/var/cache/pacman
Type=none
Options=bind


> And finally, what happens if you mount/unmount from command line (e.g. manually) /mnt/btrtop/root ?

It works as expected. It mounts and unmounts and there are no errors
and the extra nested mounting doesn't occur. I just ran through a
testing cycle of multiple mounts and unmounts to verify this.

Also, in recent days I stopped mounting and umounting /mnt/btrtop/root
and just left it mounted all the time. However, when checking today, I
still found a nested mount:

├─/srv/nfs/var/cache/pacman
│
│ └─/srv/nfs/var/cache/pacman


>
> BR
>
> > Here are the relevant lines from my fstab. I added line numbers
> > because the lines will get wrapped in email.  I don't see what part of
> > this is vague:
> >
> > 1. # cat /etc/fstab
> > 2. UUID=28D099A-9D92-487C-8113-A231CAD0EEF2  /     btrfs
> > rw,noatime,nodiratime,compress=lzo,space_cache,subvol=/@btrtop/snapshot
> > 0 0
> > 3. UUID=28D099A-9D92-487C-8113-A231CAD0EEF2  /mnt/btrtop/root  btrfs
> > noauto,nofail,rw,noatime,nodiratime,compress=lzo,space_cache    0 0
> > 4. /var/cache/pacman       /srv/nfs/var/cache/pacman       none  bind  0 0
>
> I don't know if it matters, but why you set as 'none' the filesystem type ? However according to askubuntu/stackoverflow it seem the right thing to do...

That is the way I have always done bind mounts.

I can send more complete systemd logs if needed, but this is what it
looked like hourly (before I stopped unmounting):

Aug 03 15:00:12 systemd[1]: mnt-btrtop-root.mount: Deactivated successfully.
Aug 03 16:00:06 btrbk_run.sh[2376252]: mounting btrbk btrtop volumes...
Aug 03 16:00:06 btrbk_run.sh[2376252]: OK: mounted [/mnt/btrtop/root] (1 of 3)
Aug 03 16:00:06 btrbk_run.sh[2376252]: OK: mounted [/mnt/btrtop/home] (2 of 3)
Aug 03 16:00:06 btrbk_run.sh[2376252]: OK: mounted mount
[/mnt/btrtop/user] (3 of 3)
Aug 03 16:00:06 btrbk_run.sh[2376252]: Finished mounting btrbk btrtop volumes.
Aug 03 16:00:11 btrbk_run.sh[2376356]: un-mounting btrbk btrtop volumes...
Aug 03 16:00:11 btrbk_run.sh[2376356]: OK: un-mounted
[/mnt/btrtop/user] (1 of 3)
Aug 03 16:00:11 systemd[1]: mnt-btrtop-user.mount: Deactivated successfully.
Aug 03 16:00:11 btrbk_run.sh[2376356]: OK: un-mounted
[/mnt/btrtop/home] (2 of 3)
Aug 03 16:00:11 systemd[1]: mnt-btrtop-home.mount: Deactivated successfully.
Aug 03 16:00:11 btrbk_run.sh[2376356]: OK: un-mounted
[/mnt/btrtop/root] (3 of 3)
Aug 03 16:00:11 btrbk_run.sh[2376356]: Finished un-mounting btrbk
btrtop volumes.
Aug 03 16:00:11 systemd[1]: mnt-btrtop-root.mount: Deactivated successfully.
Aug 03 17:00:06 btrbk_run.sh[2387185]: mounting btrbk btrtop volumes...
Aug 03 17:00:06 btrbk_run.sh[2387185]: OK: mounted [/mnt/btrtop/root] (1 of 3)
Aug 03 17:00:06 btrbk_run.sh[2387185]: OK: mounted [/mnt/btrtop/home] (2 of 3)
Aug 03 17:00:06 btrbk_run.sh[2387185]: OK: mounted mount
[/mnt/btrtop/user] (3 of 3)
Aug 03 17:00:06 btrbk_run.sh[2387185]: Finished mounting btrbk btrtop volumes.
Aug 03 17:00:10 btrbk_run.sh[2387275]: un-mounting btrbk btrtop volumes...
Aug 03 17:00:10 btrbk_run.sh[2387275]: OK: un-mounted
[/mnt/btrtop/user] (1 of 3)
Aug 03 17:00:10 systemd[1]: mnt-btrtop-user.mount: Deactivated successfully.
Aug 03 17:00:10 btrbk_run.sh[2387275]: OK: un-mounted
[/mnt/btrtop/home] (2 of 3)
Aug 03 17:00:10 systemd[1]: mnt-btrtop-home.mount: Deactivated successfully.
Aug 03 17:00:10 btrbk_run.sh[2387275]: OK: un-mounted
[/mnt/btrtop/root] (3 of 3)
Aug 03 17:00:10 btrbk_run.sh[2387275]: Finished un-mounting btrbk
btrtop volumes.
Aug 03 17:00:10 systemd[1]: mnt-btrtop-root.mount: Deactivated successfully.
Aug 03 18:00:06 btrbk_run.sh[2398488]: mounting btrbk btrtop volumes...

As mentioned, I have (temporarily) stopped unmounting these volumes
and I just leave them mounted all the time. The logs now look like
this:

Aug 06 03:00:14 btrbk_run.sh[3022708]: mounting btrbk btrtop volumes...
Aug 06 03:00:14 btrbk_run.sh[3022708]: INFO: [/mnt/btrtop/root] (1 of
3) was already mounted. Nothing to do.
Aug 06 03:00:14 btrbk_run.sh[3022708]: INFO: [/mnt/btrtop/home] (2 of
3) was already mounted. Nothing to do.
Aug 06 03:00:14 btrbk_run.sh[3022708]: INFO: [/mnt/btrtop/user] (3 of
3) was already mounted. Nothing to do.
Aug 06 03:00:14 btrbk_run.sh[3022708]: Finished mounting btrbk btrtop volumes.
Aug 06 04:00:14 btrbk_run.sh[3033520]: mounting btrbk btrtop volumes...
Aug 06 04:00:14 btrbk_run.sh[3033520]: INFO: [/mnt/btrtop/root] (1 of
3) was already mounted. Nothing to do.
Aug 06 04:00:14 btrbk_run.sh[3033520]: INFO: [/mnt/btrtop/home] (2 of
3) was already mounted. Nothing to do.
Aug 06 04:00:14 btrbk_run.sh[3033520]: INFO: [/mnt/btrtop/user] (3 of
3) was already mounted. Nothing to do.
Aug 06 04:00:14 btrbk_run.sh[3033520]: Finished mounting btrbk btrtop volumes.

>
> >
> > The path /var/cache/pacman is not a subvolume, but it resides on btrfs
> > subvolume @btrtop/snapshot. @btrtop/snapshot is normally mounted at
> > "/" but for btrfs tasks, it is also mounted at /mnt/btrtop/root. This
> > additional mount operation seems to be causing these nested mounts of
> > my bind mount for  /srv/nfs/var/cache/pacman .
> >
> > P.S. I cannot test without using systemd. (I'm not even sure I
> > remember how to use a non-systemd distro anymore!)
> >
>
>
> --
> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
> Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

  reply	other threads:[~2021-08-09 20:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 16:46 why is the same mount point repeatedly mounted in nested manner? Dave T
2021-08-05 17:47 ` Phillip Susi
2021-08-05 20:41   ` Dave T
2021-08-07 23:58     ` Adam Borowski
2021-08-09  4:50       ` Chris Murphy
2021-08-08 11:21 ` devel
2021-08-08 19:48   ` Dave T
2021-08-09 19:29     ` Goffredo Baroncelli
2021-08-09 20:15       ` Dave T [this message]
2021-08-10 15:43         ` Goffredo Baroncelli
2021-08-10 16:03           ` Dave T
2021-08-10 16:17             ` Goffredo Baroncelli
2021-08-10 16:27               ` Dave T
2021-08-10 20:17                 ` Goffredo Baroncelli
2021-08-10 20:36                   ` Dave T
2021-11-06  4:14                     ` Dave T

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGdWbB7KOzsWUEJWtKDfTD-hXOeh+Rhvk1iuXeRMjdqxVhA_uw@mail.gmail.com \
    --to=davestechshop@gmail.com \
    --cc=devel@roosoft.ltd.uk \
    --cc=kilobyte@angband.pl \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=phill@thesusis.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.