All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ritika Srivastava <ritika.srivastava@oracle.com>
To: Benjamin Marzinski <bmarzins@redhat.com>
Cc: "dm-devel@redhat.com" <dm-devel@redhat.com>,
	Martin Wilck <martin.wilck@suse.com>
Subject: Re: [dm-devel] [PATCH] kpartx: Add -P option for partition scanning
Date: Wed, 2 Mar 2022 00:07:11 +0000	[thread overview]
Message-ID: <1C4A63A7-0ABB-4A26-9C4A-4BD4EA192B1A@oracle.com> (raw)
In-Reply-To: <20220228224435.GY24684@octiron.msp.redhat.com>

On 2/28/22, 2:44 PM, "Benjamin Marzinski" wrote:

    > So unless I'm missing something, we'd only really want this for removing
    > a kpartx device, in the case where somehow you have /dev/loopXpY
    > partitions without the LO_FLAGS_PARTSCAN flag set on the disk. That

That's correct. We only want this option so that once PARTSCAN flag is set, 
Kpartx -d can delete /dev/loopXpY.

    > seems like it shouldn't happen in the first place.  Obviously, you
    > showed that it can with parted.  But I would argue that this is a bug in
    > parted.  If parted is creating partitions, it should set
    > LO_FLAGS_PARTSCAN so the partition nodes get cleaned up.
    > I suppose kpartx could check if there are partition devices for the loop
    > device, and if so, it could set LO_FLAGS_PARTSCAN before doing the

Would removing all partition nodes (/dev/loop0pY) on kpartx -d be a better solution.?

    > remove. But setting it unilaterally would just cause it to create an
    > extra set of devices that would only serve to confuse people (and lvm).

-P should be used only when partition scan needs to be enabled - only on need basis.

    > Also, the actual partition /dev/loopXpY will always get removed. It's
    > just the devnode that stays around, and that won't confuse lvm. This

The example below shows that /dev/loop0p1 is not removed which is confusing the LVM.

    > isn't that odd for loop devices. The /dev/loopX devnodes will stay
    > around once you're done with them, regardless of whether you create the
    > loop device will kpartx or losetup.

That's correct.
But loop device when setup with losetup -P option does remove /dev/loopXpY on detach
Hoping to achieve the same functionality in kpartx.


    >> 
    >> // workaround - losetup -P
    >> # kpartx -a -v test.img                                                                             // First kpartx
    >> # ls -l /dev/loop0*
    >> brw-rw----. 1 root disk  7,   0 Feb 22 20:05 /dev/loop0
    >> 
    >> # parted -a none -s /dev/loop0 mkpart primary 64s 100000s
    >> # parted -a none -s /dev/loop0 set 1 lvm on
    >> # kpartx -d test.img  
    >> # ls -l /dev/loop0*
    >> brw-rw----. 1 root disk   7,   0 Feb 22 20:05 /dev/loop0
    >> brw-rw----. 1 root disk 259,   0 Feb 22 20:05 /dev/loop0p1
    >> 
    >> # kpartx -av test.img                                                                         //Second kpartx
    >> # ls -l /dev/mapper/loop0*
    >> lrwxrwxrwx. 1 root root       7 Feb 22 20:53 loop0p1 -> ../dm-2
    >> 
    >> # pvcreate /dev/mapper/loop0p1
    >> # pvscan
    >>   WARNING: Not using device /dev/loop0p1 for PV <UUID>
    >>   WARNING: PV <UUID> prefers device /dev/mapper/loop0p1 because device is in dm subsystem.

    > So this example shows exactly why I don't want both /dev/loopXpY and
    > /dev/mapper/loopXpY. Whenever we use your -P option we can run into
    > this situation, right?

In the above example, the first `kpartx -a` could benefit from `-P` option and would remove /dev/loop0p1 on kpartx -d.
This is to avoid having both /dev/loop0p1 and /dev/mapper/loop0p1.

The second `kpartx -a` does not need a partition scan and `-P` option should not be provided.
However, yes, you are right - if it is specified in this case, it would create both /dev/loop0p1 and /dev/mapper/loop0p1 
- which then would have to be deleted and recreated without the `-P` option.
Maybe a warning message here would help - something like `-P` option should be used only while creating new partitions. 

Thanks,
Ritika


--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


  reply	other threads:[~2022-03-02  0:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-11 20:41 [dm-devel] [PATCH] kpartx: Add -P option for partition scanning Ritika Srivastava
2022-02-22 18:16 ` Ritika Srivastava
2022-02-22 18:27 ` Benjamin Marzinski
2022-02-22 18:59   ` Ritika Srivastava
2022-02-22 19:31     ` Benjamin Marzinski
2022-02-22 22:16       ` Ritika Srivastava
2022-02-28 22:44         ` Benjamin Marzinski
2022-03-02  0:07           ` Ritika Srivastava [this message]
2022-03-02 18:38             ` Benjamin Marzinski
2022-03-03 10:57               ` Martin Wilck
2022-03-03 17:38                 ` Ritika Srivastava
2022-02-11 22:34 Ritika Srivastava

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=1C4A63A7-0ABB-4A26-9C4A-4BD4EA192B1A@oracle.com \
    --to=ritika.srivastava@oracle.com \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=martin.wilck@suse.com \
    /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.