* why is the same mount point repeatedly mounted in nested manner? @ 2021-08-05 16:46 Dave T 2021-08-05 17:47 ` Phillip Susi 2021-08-08 11:21 ` devel 0 siblings, 2 replies; 16+ messages in thread From: Dave T @ 2021-08-05 16:46 UTC (permalink / raw) To: Btrfs BTRFS I recently switched from snapper and snapsync to btrbk, which I generally prefer. However, I am running into one issue. Background - from https://digint.ch/btrbk/doc/faq.html Btrbk is designed to operate on the subvolumes within a root subvolume. The author recommend booting linux from a btrfs subvolume, and using the btrfs root only as a container for subvolumes (i.e. NOT booting from "subvolid=5"). That's exactly what I'm doing. The key point is that btrbk requires mounting the toplevel subvolume to perform its tasks. I'm using btrbk via a systemd timer. I have a daily and hourly timer set up. Each timer starts by mounting the btrfs root, performing the btrbk task, and unmounting the btrfs root. I create hourly snapshots and on a daily basis I use btrbk to transfer those to two different USB HDD's as well as to a remote server via SSH. Here's the problem. I now end up (after some time) with a nested list of mounts for one particular mount point as shown below. I don't understand why or how this is happening. It does have side effects (disk access can hang). The apparent "cure" is to restart the nfs server service, but I'm still trying to understand the issue fully. # cat /etc/fstab UUID=28D099A-9D92-487C-8113-A231CAD0EEF2 / btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvol=/@btrtop/snapshot 0 0 #mounts my root filesystem UUID=28D099A-9D92-487C-8113-A231CAD0EEF2 /mnt/btrtop/root btrfs noauto,nofail,rw,noatime,nodiratime,compress=lzo,space_cache 0 0 #mounts the top btrfs volume for btrbk access to all snapshots /var/cache/pacman /srv/nfs/var/cache/pacman none bind 0 0 # findmnt -t btrfs TARGET SOURCE FSTYPE OPTIONS / /dev/mapper/xyz[/@btrtop/snapshot] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot ├─/srv/nfs/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot │ └─/srv/nfs/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot │ └─/srv/nfs/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot │ └─/srv/nfs/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot │ └─/srv/nfs/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot │ └─/srv/nfs/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot │ └─/srv/nfs/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot │ └─/srv/nfs/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot ├─/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot │ └─/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot │ └─/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot │ └─/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot │ └─/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot │ └─/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot │ └─/var/cache/pacman /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 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-08 11:21 ` devel 1 sibling, 1 reply; 16+ messages in thread From: Phillip Susi @ 2021-08-05 17:47 UTC (permalink / raw) To: Dave T; +Cc: Btrfs BTRFS Dave T <davestechshop@gmail.com> writes: > I'm using btrbk via a systemd timer. I have a daily and hourly timer > set up. Each timer starts by mounting the btrfs root, performing the > btrbk task, and unmounting the btrfs root. It looks like the unmounting is not being done, so it just keeps mounting it over again on the next backup. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 2021-08-05 17:47 ` Phillip Susi @ 2021-08-05 20:41 ` Dave T 2021-08-07 23:58 ` Adam Borowski 0 siblings, 1 reply; 16+ messages in thread From: Dave T @ 2021-08-05 20:41 UTC (permalink / raw) To: Btrfs BTRFS; +Cc: Phillip Susi On Thu, Aug 5, 2021 at 1:49 PM Phillip Susi <phill@thesusis.net> wrote: > > > Dave T <davestechshop@gmail.com> writes: > > > I'm using btrbk via a systemd timer. I have a daily and hourly timer > > set up. Each timer starts by mounting the btrfs root, performing the > > btrbk task, and unmounting the btrfs root. > > It looks like the unmounting is not being done, so it just keeps > mounting it over again on the next backup. > Not exactly... that path should not be unmounted. I do not mount that location explicitly for the btrbk tasks. It is mounted when the server boots up with the bind mount line I showed in fstab: /var/cache/pacman /srv/nfs/var/cache/pacman none bind 0 0 It should not be unmounted (or remounted) just because the top level btrfs volume is (un)mounted for btrbk tasks. That's the part that is confusing me. There is no command associated with my btrbk tasks that mounts /srv/nfs/var/cache/pacman (or /var/cache/pacman). There's no other entry in fstab for it except the bind mount I showed. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 2021-08-05 20:41 ` Dave T @ 2021-08-07 23:58 ` Adam Borowski 2021-08-09 4:50 ` Chris Murphy 0 siblings, 1 reply; 16+ messages in thread From: Adam Borowski @ 2021-08-07 23:58 UTC (permalink / raw) To: Dave T; +Cc: Btrfs BTRFS, Phillip Susi On Thu, Aug 05, 2021 at 04:41:03PM -0400, Dave T wrote: > On Thu, Aug 5, 2021 at 1:49 PM Phillip Susi <phill@thesusis.net> wrote: > > Dave T <davestechshop@gmail.com> writes: > > > > > I'm using btrbk via a systemd timer. I have a daily and hourly timer > > > set up. Each timer starts by mounting the btrfs root, performing the > > > btrbk task, and unmounting the btrfs root. > Not exactly... that path should not be unmounted. I do not mount that > location explicitly for the btrbk tasks. It is mounted when the server > boots up with the bind mount line I showed in fstab: > > /var/cache/pacman /srv/nfs/var/cache/pacman none bind 0 0 > > It should not be unmounted (or remounted) just because the top level > btrfs volume is (un)mounted for btrbk tasks. That's the part that is > confusing me. > > There is no command associated with my btrbk tasks that mounts > /srv/nfs/var/cache/pacman (or /var/cache/pacman). There's no other > entry in fstab for it except the bind mount I showed. I've seen systemd randomly mount and/or unmount filesystems listed in fstab when their state somehow differs from what systemd thinks should be (which can happen either by you or a program doing a mount, or due to systemd misreading the state reported by the kernel). So I wonder, can you test with an init/rc other than systemd? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables ⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice. ⠈⠳⣄⠀⠀⠀⠀ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 2021-08-07 23:58 ` Adam Borowski @ 2021-08-09 4:50 ` Chris Murphy 0 siblings, 0 replies; 16+ messages in thread From: Chris Murphy @ 2021-08-09 4:50 UTC (permalink / raw) To: Adam Borowski; +Cc: Dave T, Btrfs BTRFS, Phillip Susi On Sat, Aug 7, 2021 at 6:25 PM Adam Borowski <kilobyte@angband.pl> wrote: > > On Thu, Aug 05, 2021 at 04:41:03PM -0400, Dave T wrote: > > On Thu, Aug 5, 2021 at 1:49 PM Phillip Susi <phill@thesusis.net> wrote: > > > Dave T <davestechshop@gmail.com> writes: > > > > > > > I'm using btrbk via a systemd timer. I have a daily and hourly timer > > > > set up. Each timer starts by mounting the btrfs root, performing the > > > > btrbk task, and unmounting the btrfs root. > > > Not exactly... that path should not be unmounted. I do not mount that > > location explicitly for the btrbk tasks. It is mounted when the server > > boots up with the bind mount line I showed in fstab: > > > > /var/cache/pacman /srv/nfs/var/cache/pacman none bind 0 0 > > > > It should not be unmounted (or remounted) just because the top level > > btrfs volume is (un)mounted for btrbk tasks. That's the part that is > > confusing me. > > > > There is no command associated with my btrbk tasks that mounts > > /srv/nfs/var/cache/pacman (or /var/cache/pacman). There's no other > > entry in fstab for it except the bind mount I showed. > > I've seen systemd randomly mount and/or unmount filesystems listed in fstab > when their state somehow differs from what systemd thinks should be (which > can happen either by you or a program doing a mount, or due to systemd > misreading the state reported by the kernel). > > So I wonder, can you test with an init/rc other than systemd? We just need logs, systemd will put a message that it's mounting something into the journal: journalctl -b --no-hostname | grep mount -- Chris Murphy ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 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-08 11:21 ` devel 2021-08-08 19:48 ` Dave T 1 sibling, 1 reply; 16+ messages in thread From: devel @ 2021-08-08 11:21 UTC (permalink / raw) To: linux-btrfs On 05/08/2021 17:46, Dave T wrote: > I recently switched from snapper and snapsync to btrbk, which I > generally prefer. However, I am running into one issue. > > Background - from https://digint.ch/btrbk/doc/faq.html > Btrbk is designed to operate on the subvolumes within a root > subvolume. The author recommend booting linux from a btrfs subvolume, > and using the btrfs root only as a container for subvolumes (i.e. NOT > booting from "subvolid=5"). > > That's exactly what I'm doing. > > The key point is that btrbk requires mounting the toplevel subvolume > to perform its tasks. > > I'm using btrbk via a systemd timer. I have a daily and hourly timer > set up. Each timer starts by mounting the btrfs root, performing the > btrbk task, and unmounting the btrfs root. > > I create hourly snapshots and on a daily basis I use btrbk to transfer > those to two different USB HDD's as well as to a remote server via > SSH. > > Here's the problem. I now end up (after some time) with a nested list > of mounts for one particular mount point as shown below. I don't > understand why or how this is happening. It does have side effects > (disk access can hang). The apparent "cure" is to restart the nfs > server service, but I'm still trying to understand the issue fully. > > # cat /etc/fstab > UUID=28D099A-9D92-487C-8113-A231CAD0EEF2 / btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvol=/@btrtop/snapshot > 0 0 #mounts my root filesystem > UUID=28D099A-9D92-487C-8113-A231CAD0EEF2 /mnt/btrtop/root btrfs > noauto,nofail,rw,noatime,nodiratime,compress=lzo,space_cache 0 0 > #mounts the top btrfs volume for btrbk access to all snapshots > /var/cache/pacman /srv/nfs/var/cache/pacman none bind 0 0 > > # findmnt -t btrfs > TARGET SOURCE > FSTYPE OPTIONS > / > /dev/mapper/xyz[/@btrtop/snapshot] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > ├─/srv/nfs/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > │ └─/srv/nfs/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > │ └─/srv/nfs/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > │ └─/srv/nfs/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > │ └─/srv/nfs/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > │ └─/srv/nfs/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > │ └─/srv/nfs/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > │ └─/srv/nfs/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > ├─/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > │ └─/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > │ └─/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > │ └─/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > │ └─/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > │ └─/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > │ └─/var/cache/pacman > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot 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. -- == D Alexander ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 2021-08-08 11:21 ` devel @ 2021-08-08 19:48 ` Dave T 2021-08-09 19:29 ` Goffredo Baroncelli 0 siblings, 1 reply; 16+ messages in thread From: Dave T @ 2021-08-08 19:48 UTC (permalink / raw) To: devel, linux-btrfs; +Cc: Phillip Susi, kilobyte On Sun, Aug 8, 2021 at 8:10 AM <devel@roosoft.ltd.uk> wrote: > > On 05/08/2021 17:46, Dave T wrote: > > I recently switched from snapper and snapsync to btrbk, which I > > generally prefer. However, I am running into one issue. > > > > Background - from https://digint.ch/btrbk/doc/faq.html > > Btrbk is designed to operate on the subvolumes within a root > > subvolume. The author recommend booting linux from a btrfs subvolume, > > and using the btrfs root only as a container for subvolumes (i.e. NOT > > booting from "subvolid=5"). > > > > That's exactly what I'm doing. > > > > The key point is that btrbk requires mounting the toplevel subvolume > > to perform its tasks. > > > > I'm using btrbk via a systemd timer. I have a daily and hourly timer > > set up. Each timer starts by mounting the btrfs root, performing the > > btrbk task, and unmounting the btrfs root. > > > > I create hourly snapshots and on a daily basis I use btrbk to transfer > > those to two different USB HDD's as well as to a remote server via > > SSH. > > > > Here's the problem. I now end up (after some time) with a nested list > > of mounts for one particular mount point as shown below. I don't > > understand why or how this is happening. It does have side effects > > (disk access can hang). The apparent "cure" is to restart the nfs > > server service, but I'm still trying to understand the issue fully. > > > > # cat /etc/fstab > > UUID=28D099A-9D92-487C-8113-A231CAD0EEF2 / btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvol=/@btrtop/snapshot > > 0 0 #mounts my root filesystem > > UUID=28D099A-9D92-487C-8113-A231CAD0EEF2 /mnt/btrtop/root btrfs > > noauto,nofail,rw,noatime,nodiratime,compress=lzo,space_cache 0 0 > > #mounts the top btrfs volume for btrbk access to all snapshots > > /var/cache/pacman /srv/nfs/var/cache/pacman none bind 0 0 > > > > # findmnt -t btrfs > > TARGET SOURCE > > FSTYPE OPTIONS > > / > > /dev/mapper/xyz[/@btrtop/snapshot] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > ├─/srv/nfs/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > │ └─/srv/nfs/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > │ └─/srv/nfs/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > │ └─/srv/nfs/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > │ └─/srv/nfs/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > │ └─/srv/nfs/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > │ └─/srv/nfs/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > │ └─/srv/nfs/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > ├─/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > │ └─/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > │ └─/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > │ └─/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > │ └─/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > │ └─/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > │ └─/var/cache/pacman > > /dev/mapper/xyz[/@btrtop/snapshot/var/cache/pacman] btrfs > > rw,noatime,nodiratime,compress=lzo,space_cache,subvolid=3194,subvol=/@btrtop/snapshot > > 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. 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 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!) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 2021-08-08 19:48 ` Dave T @ 2021-08-09 19:29 ` Goffredo Baroncelli 2021-08-09 20:15 ` Dave T 0 siblings, 1 reply; 16+ messages in thread From: Goffredo Baroncelli @ 2021-08-09 19:29 UTC (permalink / raw) To: Dave T, devel, linux-btrfs; +Cc: Phillip Susi, kilobyte 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 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. And finally, what happens if you mount/unmount from command line (e.g. manually) /mnt/btrtop/root ? 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... > > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 2021-08-09 19:29 ` Goffredo Baroncelli @ 2021-08-09 20:15 ` Dave T 2021-08-10 15:43 ` Goffredo Baroncelli 0 siblings, 1 reply; 16+ messages in thread From: Dave T @ 2021-08-09 20:15 UTC (permalink / raw) To: kreijack; +Cc: devel, linux-btrfs, Phillip Susi, kilobyte 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 2021-08-09 20:15 ` Dave T @ 2021-08-10 15:43 ` Goffredo Baroncelli 2021-08-10 16:03 ` Dave T 0 siblings, 1 reply; 16+ messages in thread From: Goffredo Baroncelli @ 2021-08-10 15:43 UTC (permalink / raw) To: Dave T; +Cc: devel, linux-btrfs, Phillip Susi, kilobyte On 8/9/21 10:15 PM, Dave T wrote: > On Mon, Aug 9, 2021 at 3:29 PM Goffredo Baroncelli <kreijack@libero.it> wrote: >> [...] > > 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 > > Ok, so it seems that these mounts are triggered not by the mount of /mnt/btrtop/root (see below). What is the output of $ systemctl --reverse list-dependencies -- srv-nfs-var-cache-pacman.mount [...] > > 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. This told another story. It seems that "btrbk" itself already try to mount the btrfs subvolume. I understood that it was the systemd unit to do that. Could you share the content of btrbk_run.sh ? > 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 -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 2021-08-10 15:43 ` Goffredo Baroncelli @ 2021-08-10 16:03 ` Dave T 2021-08-10 16:17 ` Goffredo Baroncelli 0 siblings, 1 reply; 16+ messages in thread From: Dave T @ 2021-08-10 16:03 UTC (permalink / raw) To: kreijack; +Cc: devel, linux-btrfs, Phillip Susi, kilobyte On Tue, Aug 10, 2021 at 11:43 AM Goffredo Baroncelli <kreijack@inwind.it> wrote: > > On 8/9/21 10:15 PM, Dave T wrote: > > On Mon, Aug 9, 2021 at 3:29 PM Goffredo Baroncelli <kreijack@libero.it> wrote: > >> > [...] > > > > > 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 > > > > > > Ok, so it seems that these mounts are triggered not by the mount of /mnt/btrtop/root (see below). What is the output of > > $ systemctl --reverse list-dependencies -- srv-nfs-var-cache-pacman.mount > srv-nfs-var-cache-pacman.mount ● ├─nfs-server.service ● └─local-fs.target ● └─sysinit.target ○ ├─btrbk-daily.service ● ├─btrbk-daily.timer ○ ├─btrbk.service ● ├─btrbk.timer ● ├─dbus.service ● ├─dbus.socket ● ├─dhcpcd.service ● ├─getty@tty1.service ● ├─gssproxy.service ○ ├─keymap_ds.service ○ ├─logrotate.service ● ├─logrotate.timer ○ ├─man-db.service ● ├─man-db.timer ○ ├─nfs-utils.service ○ ├─users_permissions.service ● ├─users_permissions.timer ○ ├─shadow.service ● ├─shadow.timer ○ ├─snapper-cleanup.service ● ├─snapper-cleanup.timer ● ├─sshd.service ○ ├─sshdgenkeys.service ○ ├─systemd-ask-password-wall.service ● ├─systemd-logind.service ● ├─systemd-tmpfiles-clean.timer ● ├─systemd-user-sessions.service ● ├─user-runtime-dir@1000.service ● ├─user@1000.service ● ├─basic.target ○ │ ├─initrd.target ● │ └─multi-user.target ● │ └─graphical.target ○ └─rescue.target This looks interesting -- some of those dependencies are very unexpected to me. I look forward to your take on what this output indicates. I don't understand why there is a connection between srv-nfs-var-cache-pacman.mount and btrbk.service, for example. (I included btrbk.service with source listings you requested below.) > > [...] > > > > 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. > > This told another story. It seems that "btrbk" itself already try to mount the btrfs subvolume. I understood that it was the systemd unit to do that. Could you share the content of btrbk_run.sh ? > # systemctl cat btrbk.service # /usr/lib/systemd/system/btrbk.service [Unit] Description=btrbk backup Documentation=man:btrbk(1) [Service] Type=oneshot ExecStart=/usr/bin/btrbk run # /etc/systemd/system/btrbk.service.d/override.conf [Service] ExecStart= ExecStart=/usr/local/bin/btrbk_run.sh # cat /usr/local/bin/btrbk_run.sh #!/bin/bash /usr/local/bin/btrbk_mount /usr/bin/btrbk --config /etc/btrbk/btrbk.conf run # 2021-08-05 My first troubleshooting step is to disable unmounting these shares. # /usr/local/bin/btrbk-umount # cat /usr/local/bin/btrbk_mount #!/bin/bash btrbk_mount() { echo "mounting btrbk btrtop volumes..." findmnt /mnt/btrtop/root if [[ $? -ne 0 ]]; then \ mount /mnt/btrtop/root if [[ $? -ne 0 ]]; then \ echo "ERROR: failed to mount [/mnt/btrtop/root] (1 of 3)" else echo "OK: mounted [/mnt/btrtop/root] (1 of 3)" fi else echo "INFO: [/mnt/btrtop/root] (1 of 3) was already mounted. Nothing to do." fi findmnt /mnt/btrtop/home if [[ $? -ne 0 ]]; then \ mount /mnt/btrtop/home if [[ $? -ne 0 ]]; then \ echo "ERROR: failed to mount [/mnt/btrtop/home] (2 of 3)" else echo "OK: mounted [/mnt/btrtop/home] (2 of 3)" fi else echo "INFO: [/mnt/btrtop/home] (2 of 3) was already mounted. Nothing to do." fi findmnt /mnt/btrtop/user if [[ $? -ne 0 ]]; then \ mount /mnt/btrtop/user if [[ $? -ne 0 ]]; then \ echo "ERROR: failed to mount [/mnt/btrtop/user] (3 of 3)" else echo "OK: mounted mount [/mnt/btrtop/user] (3 of 3)" fi else echo "INFO: [/mnt/btrtop/user] (3 of 3) was already mounted. Nothing to do." fi echo "Finished mounting btrbk btrtop volumes." } btrbk_mount # end of file /usr/local/bin/btrbk_mount > > > 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 > > > -- > gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> > Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 2021-08-10 16:03 ` Dave T @ 2021-08-10 16:17 ` Goffredo Baroncelli 2021-08-10 16:27 ` Dave T 0 siblings, 1 reply; 16+ messages in thread From: Goffredo Baroncelli @ 2021-08-10 16:17 UTC (permalink / raw) To: Dave T; +Cc: devel, linux-btrfs, Phillip Susi, kilobyte On 8/10/21 6:03 PM, Dave T wrote: > On Tue, Aug 10, 2021 at 11:43 AM Goffredo Baroncelli <kreijack@inwind.it> wrote: >> >> On 8/9/21 10:15 PM, Dave T wrote: >>> On Mon, Aug 9, 2021 at 3:29 PM Goffredo Baroncelli <kreijack@libero.it> wrote: >>>> >> [...] >> >>> >>> 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 >>> >>> >> >> Ok, so it seems that these mounts are triggered not by the mount of /mnt/btrtop/root (see below). What is the output of >> >> $ systemctl --reverse list-dependencies -- srv-nfs-var-cache-pacman.mount >> > > srv-nfs-var-cache-pacman.mount > ● ├─nfs-server.service > ● └─local-fs.target > ● └─sysinit.target > ○ ├─btrbk-daily.service > ● ├─btrbk-daily.timer > ○ ├─btrbk.service > ● ├─btrbk.timer > ● ├─dbus.service > ● ├─dbus.socket > ● ├─dhcpcd.service > ● ├─getty@tty1.service > ● ├─gssproxy.service > ○ ├─keymap_ds.service > ○ ├─logrotate.service > ● ├─logrotate.timer > ○ ├─man-db.service > ● ├─man-db.timer > ○ ├─nfs-utils.service > ○ ├─users_permissions.service > ● ├─users_permissions.timer > ○ ├─shadow.service > ● ├─shadow.timer > ○ ├─snapper-cleanup.service > ● ├─snapper-cleanup.timer > ● ├─sshd.service > ○ ├─sshdgenkeys.service > ○ ├─systemd-ask-password-wall.service > ● ├─systemd-logind.service > ● ├─systemd-tmpfiles-clean.timer > ● ├─systemd-user-sessions.service > ● ├─user-runtime-dir@1000.service > ● ├─user@1000.service > ● ├─basic.target > ○ │ ├─initrd.target > ● │ └─multi-user.target > ● │ └─graphical.target > ○ └─rescue.target > > > This looks interesting -- some of those dependencies are very > unexpected to me. I look forward to your take on what this output > indicates. I don't understand why there is a connection between > srv-nfs-var-cache-pacman.mount and btrbk.service, for example. (I > included btrbk.service with source listings you requested below.) The btrbk.* units are triggered by sysinit.target. And sysinit requires local-fs.target, which in turn requires that all fstab mounts are mounted (then the link to srv-nfs-var-cache-pacman.mount). There no is any direct connection between btrbk and srv-nfs-var-cache-pacman.mount. What is more interesting is the dependencies between srv-nfs-var-cache-pacman.mount and nfs-server.service. I suspect (but I don't have any proof) that systemd is confused by the tuple {btrfs subvolume, bind mount, nfs dependecies}. What happens if you restart the nfs-server ? > >> >> [...] >>> >>> 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. >> >> This told another story. It seems that "btrbk" itself already try to mount the btrfs subvolume. I understood that it was the systemd unit to do that. Could you share the content of btrbk_run.sh ? >> > > # systemctl cat btrbk.service > # /usr/lib/systemd/system/btrbk.service > [Unit] > Description=btrbk backup > Documentation=man:btrbk(1) > > [Service] > Type=oneshot > ExecStart=/usr/bin/btrbk run > > # /etc/systemd/system/btrbk.service.d/override.conf > [Service] > ExecStart= > ExecStart=/usr/local/bin/btrbk_run.sh > > > # cat /usr/local/bin/btrbk_run.sh > #!/bin/bash > > /usr/local/bin/btrbk_mount > > /usr/bin/btrbk --config /etc/btrbk/btrbk.conf run > > # 2021-08-05 My first troubleshooting step is to disable unmounting > these shares. > # /usr/local/bin/btrbk-umount > > > # cat /usr/local/bin/btrbk_mount > #!/bin/bash > > btrbk_mount() { > > echo "mounting btrbk btrtop volumes..." > > findmnt /mnt/btrtop/root > if [[ $? -ne 0 ]]; then \ > mount /mnt/btrtop/root > if [[ $? -ne 0 ]]; then \ > echo "ERROR: failed to mount [/mnt/btrtop/root] (1 of 3)" > else > echo "OK: mounted [/mnt/btrtop/root] (1 of 3)" > fi > else > echo "INFO: [/mnt/btrtop/root] (1 of 3) was already mounted. Nothing to do." > fi > findmnt /mnt/btrtop/home > if [[ $? -ne 0 ]]; then \ > mount /mnt/btrtop/home > if [[ $? -ne 0 ]]; then \ > echo "ERROR: failed to mount [/mnt/btrtop/home] (2 of 3)" > else > echo "OK: mounted [/mnt/btrtop/home] (2 of 3)" > fi > else > echo "INFO: [/mnt/btrtop/home] (2 of 3) was already mounted. Nothing to do." > fi > findmnt /mnt/btrtop/user > if [[ $? -ne 0 ]]; then \ > mount /mnt/btrtop/user > if [[ $? -ne 0 ]]; then \ > echo "ERROR: failed to mount [/mnt/btrtop/user] (3 of 3)" > else > echo "OK: mounted mount [/mnt/btrtop/user] (3 of 3)" > fi > else > echo "INFO: [/mnt/btrtop/user] (3 of 3) was already mounted. Nothing to do." > fi > > echo "Finished mounting btrbk btrtop volumes." > > } > > btrbk_mount > > # end of file /usr/local/bin/btrbk_mount > > >> >>> 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 >> >> >> -- >> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> >> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 2021-08-10 16:17 ` Goffredo Baroncelli @ 2021-08-10 16:27 ` Dave T 2021-08-10 20:17 ` Goffredo Baroncelli 0 siblings, 1 reply; 16+ messages in thread From: Dave T @ 2021-08-10 16:27 UTC (permalink / raw) To: kreijack; +Cc: devel, linux-btrfs, Phillip Susi, kilobyte On Tue, Aug 10, 2021 at 12:17 PM Goffredo Baroncelli <kreijack@inwind.it> wrote: > > On 8/10/21 6:03 PM, Dave T wrote: > > On Tue, Aug 10, 2021 at 11:43 AM Goffredo Baroncelli <kreijack@inwind.it> wrote: > >> > >> On 8/9/21 10:15 PM, Dave T wrote: > >>> On Mon, Aug 9, 2021 at 3:29 PM Goffredo Baroncelli <kreijack@libero.it> wrote: > >>>> > >> [...] > >> > >>> > >>> 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 > >>> > >>> > >> > >> Ok, so it seems that these mounts are triggered not by the mount of /mnt/btrtop/root (see below). What is the output of > >> > >> $ systemctl --reverse list-dependencies -- srv-nfs-var-cache-pacman.mount > >> > > > > srv-nfs-var-cache-pacman.mount > > ● ├─nfs-server.service > > ● └─local-fs.target > > ● └─sysinit.target > > ○ ├─btrbk-daily.service > > ● ├─btrbk-daily.timer > > ○ ├─btrbk.service > > ● ├─btrbk.timer > > ● ├─dbus.service > > ● ├─dbus.socket > > ● ├─dhcpcd.service > > ● ├─getty@tty1.service > > ● ├─gssproxy.service > > ○ ├─keymap_ds.service > > ○ ├─logrotate.service > > ● ├─logrotate.timer > > ○ ├─man-db.service > > ● ├─man-db.timer > > ○ ├─nfs-utils.service > > ○ ├─users_permissions.service > > ● ├─users_permissions.timer > > ○ ├─shadow.service > > ● ├─shadow.timer > > ○ ├─snapper-cleanup.service > > ● ├─snapper-cleanup.timer > > ● ├─sshd.service > > ○ ├─sshdgenkeys.service > > ○ ├─systemd-ask-password-wall.service > > ● ├─systemd-logind.service > > ● ├─systemd-tmpfiles-clean.timer > > ● ├─systemd-user-sessions.service > > ● ├─user-runtime-dir@1000.service > > ● ├─user@1000.service > > ● ├─basic.target > > ○ │ ├─initrd.target > > ● │ └─multi-user.target > > ● │ └─graphical.target > > ○ └─rescue.target > > > > > > This looks interesting -- some of those dependencies are very > > unexpected to me. I look forward to your take on what this output > > indicates. I don't understand why there is a connection between > > srv-nfs-var-cache-pacman.mount and btrbk.service, for example. (I > > included btrbk.service with source listings you requested below.) > > The btrbk.* units are triggered by sysinit.target. And sysinit requires local-fs.target, which in turn requires that all fstab mounts are mounted (then the link to srv-nfs-var-cache-pacman.mount). > There no is any direct connection between btrbk and srv-nfs-var-cache-pacman.mount. > > What is more interesting is the dependencies between srv-nfs-var-cache-pacman.mount and nfs-server.service. I suspect (but I don't have any proof) that systemd is confused by the tuple {btrfs subvolume, bind mount, nfs dependecies}. > > What happens if you restart the nfs-server ? As part of this issue, nfs clients have been experiencing slowness and sometimes hangs. I have restarted the nfs server service a few times while this issue was happening and it seems to temporarily resolve the client issues, but I'm not 100% sure because a specific incident will resolve eventually on its own without any intervention by me. But future incidences of slowness or temporary hangs are continuing and I do think this is all related. Restarting the nfs server service does not make the nested mounts we are discussing go away. I have to unwind them with multiple calls to umount -- although the number of calls is less than the number of nested mounts, which I find confusing. Typically just 2-3 calls to umount will unmount a nesting 5-6 deep. Clients connect to a number of different nfs shares from this server, yet none of the others wind up with nested mounts like srv-nfs-var-cache-pacman.mount . All mounts are configured the same way, using the same bind mount parameters in fstab. > > > >> > >> [...] > >>> > >>> 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. > >> > >> This told another story. It seems that "btrbk" itself already try to mount the btrfs subvolume. I understood that it was the systemd unit to do that. Could you share the content of btrbk_run.sh ? > >> > > > > # systemctl cat btrbk.service > > # /usr/lib/systemd/system/btrbk.service > > [Unit] > > Description=btrbk backup > > Documentation=man:btrbk(1) > > > > [Service] > > Type=oneshot > > ExecStart=/usr/bin/btrbk run > > > > # /etc/systemd/system/btrbk.service.d/override.conf > > [Service] > > ExecStart= > > ExecStart=/usr/local/bin/btrbk_run.sh > > > > > > # cat /usr/local/bin/btrbk_run.sh > > #!/bin/bash > > > > /usr/local/bin/btrbk_mount > > > > /usr/bin/btrbk --config /etc/btrbk/btrbk.conf run > > > > # 2021-08-05 My first troubleshooting step is to disable unmounting > > these shares. > > # /usr/local/bin/btrbk-umount > > > > > > # cat /usr/local/bin/btrbk_mount > > #!/bin/bash > > > > btrbk_mount() { > > > > echo "mounting btrbk btrtop volumes..." > > > > findmnt /mnt/btrtop/root > > if [[ $? -ne 0 ]]; then \ > > mount /mnt/btrtop/root > > if [[ $? -ne 0 ]]; then \ > > echo "ERROR: failed to mount [/mnt/btrtop/root] (1 of 3)" > > else > > echo "OK: mounted [/mnt/btrtop/root] (1 of 3)" > > fi > > else > > echo "INFO: [/mnt/btrtop/root] (1 of 3) was already mounted. Nothing to do." > > fi > > findmnt /mnt/btrtop/home > > if [[ $? -ne 0 ]]; then \ > > mount /mnt/btrtop/home > > if [[ $? -ne 0 ]]; then \ > > echo "ERROR: failed to mount [/mnt/btrtop/home] (2 of 3)" > > else > > echo "OK: mounted [/mnt/btrtop/home] (2 of 3)" > > fi > > else > > echo "INFO: [/mnt/btrtop/home] (2 of 3) was already mounted. Nothing to do." > > fi > > findmnt /mnt/btrtop/user > > if [[ $? -ne 0 ]]; then \ > > mount /mnt/btrtop/user > > if [[ $? -ne 0 ]]; then \ > > echo "ERROR: failed to mount [/mnt/btrtop/user] (3 of 3)" > > else > > echo "OK: mounted mount [/mnt/btrtop/user] (3 of 3)" > > fi > > else > > echo "INFO: [/mnt/btrtop/user] (3 of 3) was already mounted. Nothing to do." > > fi > > > > echo "Finished mounting btrbk btrtop volumes." > > > > } > > > > btrbk_mount > > > > # end of file /usr/local/bin/btrbk_mount > > > > > >> > >>> 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 > >> > >> > >> -- > >> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> > >> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 > > > -- > gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> > Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 2021-08-10 16:27 ` Dave T @ 2021-08-10 20:17 ` Goffredo Baroncelli 2021-08-10 20:36 ` Dave T 0 siblings, 1 reply; 16+ messages in thread From: Goffredo Baroncelli @ 2021-08-10 20:17 UTC (permalink / raw) To: Dave T; +Cc: devel, linux-btrfs, Phillip Susi, kilobyte On 8/10/21 6:27 PM, Dave T wrote: > On Tue, Aug 10, 2021 at 12:17 PM Goffredo Baroncelli <kreijack@inwind.it> wrote: >> >> On 8/10/21 6:03 PM, Dave T wrote: >>> On Tue, Aug 10, 2021 at 11:43 AM Goffredo Baroncelli <kreijack@inwind.it> wrote: [...] >> What is more interesting is the dependencies between srv-nfs-var-cache-pacman.mount and nfs-server.service. I suspect (but I don't have any proof) that systemd is confused by the tuple {btrfs subvolume, bind mount, nfs dependecies}. >> >> What happens if you restart the nfs-server ? > > As part of this issue, nfs clients have been experiencing slowness and > sometimes hangs. I have restarted the nfs server service a few times > while this issue was happening and it seems to temporarily resolve the > client issues, but I'm not 100% sure because a specific incident will > resolve eventually on its own without any intervention by me. But > future incidences of slowness or temporary hangs are continuing and I > do think this is all related. > > Restarting the nfs server service does not make the nested mounts we > are discussing go away. I have to unwind them with multiple calls to > umount -- although the number of calls is less than the number of > nested mounts, which I find confusing. Typically just 2-3 calls to > umount will unmount a nesting 5-6 deep. > > Clients connect to a number of different nfs shares from this server, > yet none of the others wind up with nested mounts like > srv-nfs-var-cache-pacman.mount . All mounts are configured the same > way, using the same bind mount parameters in fstab. > Unfortunately I don't have any more suggestions.. My opinion is that the problem is not related to the btrfs itself, but it is more a side effect of the interaction between systemd and btrfs. What about looking to the log ? $ sudo journalctl -u srv-nfs-var-cache-pacman.mount Then check the log near the mount/unmount To avoid this problem enterely, what about using a symlink instead of the bind mount ? Something like # rmdir /srv/nfs/var/cache/pacman ; ln -sf /var/cache/pacman /srv/nfs/var/cache/pacman BR GB >>> >>>> >>>> [...] >>>>> >>>>> 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. >>>> >>>> This told another story. It seems that "btrbk" itself already try to mount the btrfs subvolume. I understood that it was the systemd unit to do that. Could you share the content of btrbk_run.sh ? >>>> >>> >>> # systemctl cat btrbk.service >>> # /usr/lib/systemd/system/btrbk.service >>> [Unit] >>> Description=btrbk backup >>> Documentation=man:btrbk(1) >>> >>> [Service] >>> Type=oneshot >>> ExecStart=/usr/bin/btrbk run >>> >>> # /etc/systemd/system/btrbk.service.d/override.conf >>> [Service] >>> ExecStart= >>> ExecStart=/usr/local/bin/btrbk_run.sh >>> >>> >>> # cat /usr/local/bin/btrbk_run.sh >>> #!/bin/bash >>> >>> /usr/local/bin/btrbk_mount >>> >>> /usr/bin/btrbk --config /etc/btrbk/btrbk.conf run >>> >>> # 2021-08-05 My first troubleshooting step is to disable unmounting >>> these shares. >>> # /usr/local/bin/btrbk-umount >>> >>> >>> # cat /usr/local/bin/btrbk_mount >>> #!/bin/bash >>> >>> btrbk_mount() { >>> >>> echo "mounting btrbk btrtop volumes..." >>> >>> findmnt /mnt/btrtop/root >>> if [[ $? -ne 0 ]]; then \ >>> mount /mnt/btrtop/root >>> if [[ $? -ne 0 ]]; then \ >>> echo "ERROR: failed to mount [/mnt/btrtop/root] (1 of 3)" >>> else >>> echo "OK: mounted [/mnt/btrtop/root] (1 of 3)" >>> fi >>> else >>> echo "INFO: [/mnt/btrtop/root] (1 of 3) was already mounted. Nothing to do." >>> fi >>> findmnt /mnt/btrtop/home >>> if [[ $? -ne 0 ]]; then \ >>> mount /mnt/btrtop/home >>> if [[ $? -ne 0 ]]; then \ >>> echo "ERROR: failed to mount [/mnt/btrtop/home] (2 of 3)" >>> else >>> echo "OK: mounted [/mnt/btrtop/home] (2 of 3)" >>> fi >>> else >>> echo "INFO: [/mnt/btrtop/home] (2 of 3) was already mounted. Nothing to do." >>> fi >>> findmnt /mnt/btrtop/user >>> if [[ $? -ne 0 ]]; then \ >>> mount /mnt/btrtop/user >>> if [[ $? -ne 0 ]]; then \ >>> echo "ERROR: failed to mount [/mnt/btrtop/user] (3 of 3)" >>> else >>> echo "OK: mounted mount [/mnt/btrtop/user] (3 of 3)" >>> fi >>> else >>> echo "INFO: [/mnt/btrtop/user] (3 of 3) was already mounted. Nothing to do." >>> fi >>> >>> echo "Finished mounting btrbk btrtop volumes." >>> >>> } >>> >>> btrbk_mount >>> >>> # end of file /usr/local/bin/btrbk_mount >>> >>> >>>> >>>>> 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 >>>> >>>> >>>> -- >>>> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> >>>> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 >> >> >> -- >> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> >> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 2021-08-10 20:17 ` Goffredo Baroncelli @ 2021-08-10 20:36 ` Dave T 2021-11-06 4:14 ` Dave T 0 siblings, 1 reply; 16+ messages in thread From: Dave T @ 2021-08-10 20:36 UTC (permalink / raw) To: kreijack; +Cc: devel, linux-btrfs, Phillip Susi, kilobyte On Tue, Aug 10, 2021 at 4:17 PM Goffredo Baroncelli <kreijack@inwind.it> wrote: > > On 8/10/21 6:27 PM, Dave T wrote: > > On Tue, Aug 10, 2021 at 12:17 PM Goffredo Baroncelli <kreijack@inwind.it> wrote: > >> > >> On 8/10/21 6:03 PM, Dave T wrote: > >>> On Tue, Aug 10, 2021 at 11:43 AM Goffredo Baroncelli <kreijack@inwind.it> wrote: > [...] > >> What is more interesting is the dependencies between srv-nfs-var-cache-pacman.mount and nfs-server.service. I suspect (but I don't have any proof) that systemd is confused by the tuple {btrfs subvolume, bind mount, nfs dependecies}. > >> > >> What happens if you restart the nfs-server ? > > > > As part of this issue, nfs clients have been experiencing slowness and > > sometimes hangs. I have restarted the nfs server service a few times > > while this issue was happening and it seems to temporarily resolve the > > client issues, but I'm not 100% sure because a specific incident will > > resolve eventually on its own without any intervention by me. But > > future incidences of slowness or temporary hangs are continuing and I > > do think this is all related. > > > > Restarting the nfs server service does not make the nested mounts we > > are discussing go away. I have to unwind them with multiple calls to > > umount -- although the number of calls is less than the number of > > nested mounts, which I find confusing. Typically just 2-3 calls to > > umount will unmount a nesting 5-6 deep. > > > > Clients connect to a number of different nfs shares from this server, > > yet none of the others wind up with nested mounts like > > srv-nfs-var-cache-pacman.mount . All mounts are configured the same > > way, using the same bind mount parameters in fstab. > > > > Unfortunately I don't have any more suggestions.. The replies you have given so far have already helped me understand the issue a little better. Thank you. > > My opinion is that the problem is not related to the btrfs itself, but it is more a side effect of the interaction between systemd and btrfs. What about looking to the log ? Yes, I agree. > > $ sudo journalctl -u srv-nfs-var-cache-pacman.mount > > Then check the log near the mount/unmount -- Boot 48833b09370b46a4ade0c1979438be90 -- Jul 24 22:29:00 nfssrvr systemd[1]: Mounting /srv/nfs/var/cache/pacman... Jul 24 22:29:00 nfssrvr systemd[1]: Mounted /srv/nfs/var/cache/pacman. -- Boot d11dc578c1c342b3a44bbf7d266c4049 -- Jul 25 12:37:31 nfssrvr systemd[1]: Mounting /srv/nfs/var/cache/pacman... Jul 25 12:37:31 nfssrvr systemd[1]: Mounted /srv/nfs/var/cache/pacman. -- Boot a4e09d4b507c4e4e949f03c3ffe11081 -- Jul 25 14:15:33 nfssrvr systemd[1]: Mounting /srv/nfs/var/cache/pacman... Jul 25 14:15:33 nfssrvr systemd[1]: Mounted /srv/nfs/var/cache/pacman. Jul 25 18:27:56 nfssrvr systemd[1]: srv-nfs-var-cache-pacman.mount: Deactivated successfully. Aug 05 11:39:10 nfssrvr systemd[1]: srv-nfs-var-cache-pacman.mount: Deactivated successfully. Those last two lines are my intervention (manually unmounting). I don't see anything else of interest to this in the logs. > > To avoid this problem enterely, what about using a symlink instead of the bind mount ? > > Something like > > # rmdir /srv/nfs/var/cache/pacman ; ln -sf /var/cache/pacman /srv/nfs/var/cache/pacman As far as I know, that's not a recommended practice for NFS shares. I don't know why. I'll look into it. Thanks for the idea. > > > BR > GB > > >>> > >>>> > >>>> [...] > >>>>> > >>>>> 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. > >>>> > >>>> This told another story. It seems that "btrbk" itself already try to mount the btrfs subvolume. I understood that it was the systemd unit to do that. Could you share the content of btrbk_run.sh ? > >>>> > >>> > >>> # systemctl cat btrbk.service > >>> # /usr/lib/systemd/system/btrbk.service > >>> [Unit] > >>> Description=btrbk backup > >>> Documentation=man:btrbk(1) > >>> > >>> [Service] > >>> Type=oneshot > >>> ExecStart=/usr/bin/btrbk run > >>> > >>> # /etc/systemd/system/btrbk.service.d/override.conf > >>> [Service] > >>> ExecStart= > >>> ExecStart=/usr/local/bin/btrbk_run.sh > >>> > >>> > >>> # cat /usr/local/bin/btrbk_run.sh > >>> #!/bin/bash > >>> > >>> /usr/local/bin/btrbk_mount > >>> > >>> /usr/bin/btrbk --config /etc/btrbk/btrbk.conf run > >>> > >>> # 2021-08-05 My first troubleshooting step is to disable unmounting > >>> these shares. > >>> # /usr/local/bin/btrbk-umount > >>> > >>> > >>> # cat /usr/local/bin/btrbk_mount > >>> #!/bin/bash > >>> > >>> btrbk_mount() { > >>> > >>> echo "mounting btrbk btrtop volumes..." > >>> > >>> findmnt /mnt/btrtop/root > >>> if [[ $? -ne 0 ]]; then \ > >>> mount /mnt/btrtop/root > >>> if [[ $? -ne 0 ]]; then \ > >>> echo "ERROR: failed to mount [/mnt/btrtop/root] (1 of 3)" > >>> else > >>> echo "OK: mounted [/mnt/btrtop/root] (1 of 3)" > >>> fi > >>> else > >>> echo "INFO: [/mnt/btrtop/root] (1 of 3) was already mounted. Nothing to do." > >>> fi > >>> findmnt /mnt/btrtop/home > >>> if [[ $? -ne 0 ]]; then \ > >>> mount /mnt/btrtop/home > >>> if [[ $? -ne 0 ]]; then \ > >>> echo "ERROR: failed to mount [/mnt/btrtop/home] (2 of 3)" > >>> else > >>> echo "OK: mounted [/mnt/btrtop/home] (2 of 3)" > >>> fi > >>> else > >>> echo "INFO: [/mnt/btrtop/home] (2 of 3) was already mounted. Nothing to do." > >>> fi > >>> findmnt /mnt/btrtop/user > >>> if [[ $? -ne 0 ]]; then \ > >>> mount /mnt/btrtop/user > >>> if [[ $? -ne 0 ]]; then \ > >>> echo "ERROR: failed to mount [/mnt/btrtop/user] (3 of 3)" > >>> else > >>> echo "OK: mounted mount [/mnt/btrtop/user] (3 of 3)" > >>> fi > >>> else > >>> echo "INFO: [/mnt/btrtop/user] (3 of 3) was already mounted. Nothing to do." > >>> fi > >>> > >>> echo "Finished mounting btrbk btrtop volumes." > >>> > >>> } > >>> > >>> btrbk_mount > >>> > >>> # end of file /usr/local/bin/btrbk_mount > >>> > >>> > >>>> > >>>>> 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 > >>>> > >>>> > >>>> -- > >>>> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> > >>>> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 > >> > >> > >> -- > >> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> > >> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 > > > -- > gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> > Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: why is the same mount point repeatedly mounted in nested manner? 2021-08-10 20:36 ` Dave T @ 2021-11-06 4:14 ` Dave T 0 siblings, 0 replies; 16+ messages in thread From: Dave T @ 2021-11-06 4:14 UTC (permalink / raw) To: linux-btrfs; +Cc: devel, Phillip Susi, kilobyte, kreijack Following up on this topic, I came across this github issue today: [bind entries in fstab are made recursive regardless of options · Issue #1204 · systemd/systemd · GitHub](https://github.com/systemd/systemd/issues/1204) I think that is the explanation. I will do more testing to confirm. On Tue, Aug 10, 2021 at 4:36 PM Dave T <davestechshop@gmail.com> wrote: > > On Tue, Aug 10, 2021 at 4:17 PM Goffredo Baroncelli <kreijack@inwind.it> wrote: > > > > On 8/10/21 6:27 PM, Dave T wrote: > > > On Tue, Aug 10, 2021 at 12:17 PM Goffredo Baroncelli <kreijack@inwind.it> wrote: > > >> > > >> On 8/10/21 6:03 PM, Dave T wrote: > > >>> On Tue, Aug 10, 2021 at 11:43 AM Goffredo Baroncelli <kreijack@inwind.it> wrote: > > [...] > > >> What is more interesting is the dependencies between srv-nfs-var-cache-pacman.mount and nfs-server.service. I suspect (but I don't have any proof) that systemd is confused by the tuple {btrfs subvolume, bind mount, nfs dependecies}. > > >> > > >> What happens if you restart the nfs-server ? > > > > > > As part of this issue, nfs clients have been experiencing slowness and > > > sometimes hangs. I have restarted the nfs server service a few times > > > while this issue was happening and it seems to temporarily resolve the > > > client issues, but I'm not 100% sure because a specific incident will > > > resolve eventually on its own without any intervention by me. But > > > future incidences of slowness or temporary hangs are continuing and I > > > do think this is all related. > > > > > > Restarting the nfs server service does not make the nested mounts we > > > are discussing go away. I have to unwind them with multiple calls to > > > umount -- although the number of calls is less than the number of > > > nested mounts, which I find confusing. Typically just 2-3 calls to > > > umount will unmount a nesting 5-6 deep. > > > > > > Clients connect to a number of different nfs shares from this server, > > > yet none of the others wind up with nested mounts like > > > srv-nfs-var-cache-pacman.mount . All mounts are configured the same > > > way, using the same bind mount parameters in fstab. > > > > > > > Unfortunately I don't have any more suggestions.. > > The replies you have given so far have already helped me understand > the issue a little better. Thank you. > > > > My opinion is that the problem is not related to the btrfs itself, but it is more a side effect of the interaction between systemd and btrfs. What about looking to the log ? > > Yes, I agree. > > > > > $ sudo journalctl -u srv-nfs-var-cache-pacman.mount > > > > Then check the log near the mount/unmount > > -- Boot 48833b09370b46a4ade0c1979438be90 -- > Jul 24 22:29:00 nfssrvr systemd[1]: Mounting /srv/nfs/var/cache/pacman... > Jul 24 22:29:00 nfssrvr systemd[1]: Mounted /srv/nfs/var/cache/pacman. > -- Boot d11dc578c1c342b3a44bbf7d266c4049 -- > Jul 25 12:37:31 nfssrvr systemd[1]: Mounting /srv/nfs/var/cache/pacman... > Jul 25 12:37:31 nfssrvr systemd[1]: Mounted /srv/nfs/var/cache/pacman. > -- Boot a4e09d4b507c4e4e949f03c3ffe11081 -- > Jul 25 14:15:33 nfssrvr systemd[1]: Mounting /srv/nfs/var/cache/pacman... > Jul 25 14:15:33 nfssrvr systemd[1]: Mounted /srv/nfs/var/cache/pacman. > Jul 25 18:27:56 nfssrvr systemd[1]: > srv-nfs-var-cache-pacman.mount: Deactivated successfully. > Aug 05 11:39:10 nfssrvr systemd[1]: > srv-nfs-var-cache-pacman.mount: Deactivated successfully. > > Those last two lines are my intervention (manually unmounting). I > don't see anything else of interest to this in the logs. > > > > To avoid this problem enterely, what about using a symlink instead of the bind mount ? > > > > Something like > > > > # rmdir /srv/nfs/var/cache/pacman ; ln -sf /var/cache/pacman /srv/nfs/var/cache/pacman > > As far as I know, that's not a recommended practice for NFS shares. I > don't know why. I'll look into it. Thanks for the idea. > > > > > > BR > > GB > > > > >>> > > >>>> > > >>>> [...] > > >>>>> > > >>>>> 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. > > >>>> > > >>>> This told another story. It seems that "btrbk" itself already try to mount the btrfs subvolume. I understood that it was the systemd unit to do that. Could you share the content of btrbk_run.sh ? > > >>>> > > >>> > > >>> # systemctl cat btrbk.service > > >>> # /usr/lib/systemd/system/btrbk.service > > >>> [Unit] > > >>> Description=btrbk backup > > >>> Documentation=man:btrbk(1) > > >>> > > >>> [Service] > > >>> Type=oneshot > > >>> ExecStart=/usr/bin/btrbk run > > >>> > > >>> # /etc/systemd/system/btrbk.service.d/override.conf > > >>> [Service] > > >>> ExecStart= > > >>> ExecStart=/usr/local/bin/btrbk_run.sh > > >>> > > >>> > > >>> # cat /usr/local/bin/btrbk_run.sh > > >>> #!/bin/bash > > >>> > > >>> /usr/local/bin/btrbk_mount > > >>> > > >>> /usr/bin/btrbk --config /etc/btrbk/btrbk.conf run > > >>> > > >>> # 2021-08-05 My first troubleshooting step is to disable unmounting > > >>> these shares. > > >>> # /usr/local/bin/btrbk-umount > > >>> > > >>> > > >>> # cat /usr/local/bin/btrbk_mount > > >>> #!/bin/bash > > >>> > > >>> btrbk_mount() { > > >>> > > >>> echo "mounting btrbk btrtop volumes..." > > >>> > > >>> findmnt /mnt/btrtop/root > > >>> if [[ $? -ne 0 ]]; then \ > > >>> mount /mnt/btrtop/root > > >>> if [[ $? -ne 0 ]]; then \ > > >>> echo "ERROR: failed to mount [/mnt/btrtop/root] (1 of 3)" > > >>> else > > >>> echo "OK: mounted [/mnt/btrtop/root] (1 of 3)" > > >>> fi > > >>> else > > >>> echo "INFO: [/mnt/btrtop/root] (1 of 3) was already mounted. Nothing to do." > > >>> fi > > >>> findmnt /mnt/btrtop/home > > >>> if [[ $? -ne 0 ]]; then \ > > >>> mount /mnt/btrtop/home > > >>> if [[ $? -ne 0 ]]; then \ > > >>> echo "ERROR: failed to mount [/mnt/btrtop/home] (2 of 3)" > > >>> else > > >>> echo "OK: mounted [/mnt/btrtop/home] (2 of 3)" > > >>> fi > > >>> else > > >>> echo "INFO: [/mnt/btrtop/home] (2 of 3) was already mounted. Nothing to do." > > >>> fi > > >>> findmnt /mnt/btrtop/user > > >>> if [[ $? -ne 0 ]]; then \ > > >>> mount /mnt/btrtop/user > > >>> if [[ $? -ne 0 ]]; then \ > > >>> echo "ERROR: failed to mount [/mnt/btrtop/user] (3 of 3)" > > >>> else > > >>> echo "OK: mounted mount [/mnt/btrtop/user] (3 of 3)" > > >>> fi > > >>> else > > >>> echo "INFO: [/mnt/btrtop/user] (3 of 3) was already mounted. Nothing to do." > > >>> fi > > >>> > > >>> echo "Finished mounting btrbk btrtop volumes." > > >>> > > >>> } > > >>> > > >>> btrbk_mount > > >>> > > >>> # end of file /usr/local/bin/btrbk_mount > > >>> > > >>> > > >>>> > > >>>>> 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 > > >>>> > > >>>> > > >>>> -- > > >>>> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> > > >>>> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 > > >> > > >> > > >> -- > > >> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> > > >> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 > > > > > > -- > > gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> > > Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2021-11-06 4:19 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.