All of lore.kernel.org
 help / color / mirror / Atom feed
From: Graham Cobb <g.btrfs@cobb.uk.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: "btrfs: harden agaist duplicate fsid" spams syslog
Date: Thu, 11 Jul 2019 19:00:24 +0100	[thread overview]
Message-ID: <a3d6e202-acf4-c02e-430a-aef4a2ee4247@cobb.uk.net> (raw)
In-Reply-To: <c01ab9f6-c553-3625-5656-a8f61659de7d@oracle.com>

On 11/07/2019 03:46, Anand Jain wrote:
> Now the question I am trying to understand, why same device is being
> scanned every 2 mins, even though its already mount-ed. I am guessing
> its toggling the same device paths trying to mount the device-path
> which is not mounted. So autofs's check for the device mount seems to
> be path based.
> 
> Would you please provide your LVM configs and I believe you are using
> dm-mapping too. What are the device paths used in the fstab and in grub.
> And do you see these messages for all devices of
> 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 or just devid 4? Would you please
> provide more logs at least a complete cycle of the repeating logs.

My setup is quite complex, with three btrfs-over-LVM-over-LUKS
filesystems, so I will explain it fully in a separate message in case it
is important. Let me first answer your questions regarding
4d1ba5af-8b89-4cb5-96c6-55d1f028a202, which was the example I used in my
initial log extract.

4d1b...a202 is a filesystem with a main mount point of /mnt/backup2/:

black:~# btrfs fi show /mnt/backup2/
Label: 'snap12tb'  uuid: 4d1ba5af-8b89-4cb5-96c6-55d1f028a202
        Total devices 2 FS bytes used 10.97TiB
        devid    1 size 10.82TiB used 10.82TiB path /dev/sdc3
        devid    4 size 3.62TiB used 199.00GiB path
/dev/mapper/cryptdata4tb--vg-backup

In this particular filesystem, it has two devices: one is a real disk
partition (/dev/sdc3), the other is an LVM logical volume. It has also
had other LVM devices added and removed at various times, but this is
the current setup.

Note: when I added this LV, I used path /dev/mapper/cryptdata4tb--vg-backup.

black:~# lvdisplay /dev/cryptdata4tb-vg/backup
  --- Logical volume ---
  LV Path                /dev/cryptdata4tb-vg/backup
  LV Name                backup
  VG Name                cryptdata4tb-vg
  LV UUID                TZaWfo-goG1-GsNV-GCZL-rpbz-IW0H-gNmXBf
  LV Write Access        read/write
  LV Creation host, time black, 2019-07-10 10:40:28 +0100
  LV Status              available
  # open                 1
  LV Size                3.62 TiB
  Current LE             949089
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:13

The LVM logical volume is exposed as /dev/mapper/cryptdata4tb--vg-backup
which is a symlink (set up by LVM, I believe) to /dev/dm-13.

For the 4d1b...a202 filesystem I currently only see the messages for
devid 4. But I presume that is because devid 1 is a real device, which
only appears in /dev once. I did, for a while, have two LV devices in
this filesystem and, looking at the old logs, I can see that every 2
minutes the swapping between /dev/mapper/whatever and /dev/dm-N was
happening for both LV devids (but not for the physical device devid)

This particular device is not a root device and I do not believe it is
referenced in grub or initramfs. It is mounted in /etc/fstab/:

LABEL=snap12tb  /mnt/backup2    btrfs
defaults,subvolid=0,noatime,nodiratime,compress=lzo,skip_balance,space_cache=v2
       0       3

Note that /dev/disk/by-label/snap12tb is a symlink to the dm-N alias of
the LV device (set up by LVM or udev or something - not by me):

black:~# ls -l /dev/disk/by-label/snap12tb
lrwxrwxrwx 1 root root 11 Jul 11 18:18 /dev/disk/by-label/snap12tb ->
../../dm-13

Here is a log extract of the cycling messages for the 4d1b...a202
filesystem:

Jul 11 18:46:28 black kernel: [116657.825658] BTRFS info (device sdc3):
device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved
old:/dev/mapper/cryptdata4tb--vg-backup new:/dev/dm-13
Jul 11 18:46:28 black kernel: [116658.048042] BTRFS info (device sdc3):
device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved
old:/dev/dm-13 new:/dev/mapper/cryptdata4tb--vg-backup
Jul 11 18:46:29 black kernel: [116659.157392] BTRFS info (device sdc3):
device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved
old:/dev/mapper/cryptdata4tb--vg-backup new:/dev/dm-13
Jul 11 18:46:29 black kernel: [116659.337504] BTRFS info (device sdc3):
device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved
old:/dev/dm-13 new:/dev/mapper/cryptdata4tb--vg-backup
Jul 11 18:48:28 black kernel: [116777.727262] BTRFS info (device sdc3):
device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved
old:/dev/mapper/cryptdata4tb--vg-backup new:/dev/dm-13
Jul 11 18:48:28 black kernel: [116778.019874] BTRFS info (device sdc3):
device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved
old:/dev/dm-13 new:/dev/mapper/cryptdata4tb--vg-backup
Jul 11 18:48:29 black kernel: [116779.157038] BTRFS info (device sdc3):
device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved
old:/dev/mapper/cryptdata4tb--vg-backup new:/dev/dm-13
Jul 11 18:48:30 black kernel: [116779.364959] BTRFS info (device sdc3):
device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved
old:/dev/dm-13 new:/dev/mapper/cryptdata4tb--vg-backup
Jul 11 18:50:28 black kernel: [116897.705568] BTRFS info (device sdc3):
device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved
old:/dev/mapper/cryptdata4tb--vg-backup new:/dev/dm-13
Jul 11 18:50:28 black kernel: [116897.911805] BTRFS info (device sdc3):
device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved
old:/dev/dm-13 new:/dev/mapper/cryptdata4tb--vg-backup
Jul 11 18:50:29 black kernel: [116899.053046] BTRFS info (device sdc3):
device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved
old:/dev/mapper/cryptdata4tb--vg-backup new:/dev/dm-13
Jul 11 18:50:29 black kernel: [116899.213067] BTRFS info (device sdc3):
device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved
old:/dev/dm-13 new:/dev/mapper/cryptdata4tb--vg-backup


I will, later, provide more detailed configuration information,
including the other filesystems and more logs. As that will be very long
I plan to send it directly to you, Anand, rather than to the list.

Graham

  reply	other threads:[~2019-07-11 18:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10 18:49 "btrfs: harden agaist duplicate fsid" spams syslog Graham Cobb
2019-07-11  2:46 ` Anand Jain
2019-07-11 18:00   ` Graham Cobb [this message]
2019-07-12 12:46     ` Anand Jain
2019-07-12 13:32       ` Graham Cobb
2019-07-19 15:38         ` David Sterba
2019-07-12 13:35       ` Patrik Lundquist
2019-07-12 13:41         ` Graham Cobb
2019-07-11 23:06   ` Christoph Anton Mitterer
2019-07-12 12:49     ` Anand Jain
2019-07-16 13:59 ` [PATCH] btrfs: ratelimit device path change info on mounted device Anand Jain
2019-07-16 14:08   ` Anand Jain
2019-07-19 14:58   ` David Sterba

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=a3d6e202-acf4-c02e-430a-aef4a2ee4247@cobb.uk.net \
    --to=g.btrfs@cobb.uk.net \
    --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.