All of lore.kernel.org
 help / color / mirror / Atom feed
From: devel@roosoft.ltd.uk
To: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: why is the same mount point repeatedly mounted in nested manner?
Date: Sun, 8 Aug 2021 12:21:38 +0100	[thread overview]
Message-ID: <c906060a-9dbc-e5d1-8e85-832408249b4d@casa-di-locascio.net> (raw)
In-Reply-To: <CAGdWbB59ULVxpNnq5Og0SCri+qyz_cwDLFTLr5N7iVT9gb0w1A@mail.gmail.com>

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




  parent reply	other threads:[~2021-08-08 12:08 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 [this message]
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

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=c906060a-9dbc-e5d1-8e85-832408249b4d@casa-di-locascio.net \
    --to=devel@roosoft.ltd.uk \
    --cc=linux-btrfs@vger.kernel.org \
    /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.