All of lore.kernel.org
 help / color / mirror / 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	[thread overview]
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	other threads:[~2019-07-12 12:47 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
2019-07-12 12:46     ` Anand Jain [this message]
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=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
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.