Linux-BTRFS Archive on lore.kernel.org
 help / color / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: Graham Cobb <g.btrfs@cobb.uk.net>, linux-btrfs@vger.kernel.org
Cc: calestyo@scientia.net
Subject: Re: "btrfs: harden agaist duplicate fsid" spams syslog
Date: Fri, 12 Jul 2019 20:46:59 +0800
Message-ID: <7766d592-525e-67fa-5db0-bcfff17fbf83@oracle.com> (raw)
In-Reply-To: <a3d6e202-acf4-c02e-430a-aef4a2ee4247@cobb.uk.net>



I am unable to reproduce, I have tried with/without dm-crypt on both
oraclelinux and opensuse (I am yet to try debian).

The patch in $subject is fair, but changing device path indicates
there is some problem in the system. However, I didn't expect
same device pointed by both /dev/dm-x and /dev/mapper/abc would
contended.

One fix for this is to make it a ratelimit print. But then the same
thing happens without notice. If you monitor /proc/self/mounts
probably you will notice that mount device changes every ~2mins.

I will be more keen to find the module which is causing this issue,
that is calling 'btrfs dev scan' every ~2mins or trying to mount
an unmounted device without understanding that its mapper is already
mounted.

Thanks, Anand



On 12/7/19 2:00 AM, Graham Cobb wrote:
> 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 index

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10 18:49 Graham Cobb
2019-07-11  2:46 ` Anand Jain
2019-07-11 18:00   ` Graham Cobb
2019-07-12 12:46     ` Anand Jain [this message]
2019-07-12 13:32       ` Graham Cobb
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

Reply instructions:

You may reply publically 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=7766d592-525e-67fa-5db0-bcfff17fbf83@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=calestyo@scientia.net \
    --cc=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

Linux-BTRFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-btrfs/0 linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ https://lore.kernel.org/linux-btrfs \
		linux-btrfs@vger.kernel.org linux-btrfs@archiver.kernel.org
	public-inbox-index linux-btrfs


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-btrfs


AGPL code for this site: git clone https://public-inbox.org/ public-inbox