linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Peter Rajnoha <prajnoha@redhat.com>
To: Martin Wilck <martin.wilck@suse.com>,
	Zdenek Kabelac <zkabelac@redhat.com>,
	Benjamin Marzinski <bmarzins@redhat.com>,
	David Teigland <teigland@redhat.com>
Cc: linux-lvm@lists.linux.dev, dm-devel@lists.linux.dev,
	Martin Wilck <mwilck@suse.com>, Hannes Reinecke <hare@suse.de>
Subject: Re: [RFC PATCH 1/7] 13-dm-disk.rules: import ID_FS_TYPE
Date: Mon, 4 Mar 2024 11:37:38 +0100	[thread overview]
Message-ID: <f82c786b-4b8e-4e5a-a049-bd4cfba668bd@redhat.com> (raw)
In-Reply-To: <20240301224011.11117-2-mwilck@suse.com>

On 3/1/24 23:40, Martin Wilck wrote:
> ID_FS_TYPE is the most important udev property for most follow-up
> rules. It must be imported from the udev db if blkid can't be run.
> 
> Signed-off-by: Martin Wilck <mwilck@suse.com>
> ---
>  udev/13-dm-disk.rules.in | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/udev/13-dm-disk.rules.in b/udev/13-dm-disk.rules.in
> index dca00bc..eaad972 100644
> --- a/udev/13-dm-disk.rules.in
> +++ b/udev/13-dm-disk.rules.in
> @@ -26,6 +26,7 @@ ENV{DM_NOSCAN}=="1", GOTO="dm_watch"
>  GOTO="dm_link"
>  
>  LABEL="dm_import"
> +IMPORT{db}="ID_FS_TYPE"
>  IMPORT{db}="ID_FS_USAGE"
>  IMPORT{db}="ID_FS_UUID_ENC"
>  IMPORT{db}="ID_FS_LABEL_ENC"

I think this one was left out deliberately. The original intention was
to import only the minimal set of "blkid" variables needed to properly
keep the symlinks based on these values in place (patch 94f77a4). And
the "ID_FS_TYPE" is not actually needed for this.

Though, importing even the "ID_FS_TYPE" together with other blkid
variables should not be an issue because this "import from previous
state" happens only if we have DM_SUSPENDED or DM_NOSCAN set for current
event, in which case any other rules should be also disabled with
DM_UDEV_DISABLE_OTHER_RULES_FLAG="1".

So even if some other rule fires based on ID_FS_TYPE value, the
DM_UDEV_DISABLE_OTHER_RULES_FLAG should stop it anyway.

Then, the question is whether we really need to 'IMPORT{db}="ID_FS_TYPE'?

-- 
Peter


  reply	other threads:[~2024-03-04 10:37 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-01 22:40 [RFC PATCH 0/7] device mapper udev rules rework Martin Wilck
2024-03-01 22:40 ` [RFC PATCH 1/7] 13-dm-disk.rules: import ID_FS_TYPE Martin Wilck
2024-03-04 10:37   ` Peter Rajnoha [this message]
2024-03-04 15:17     ` Martin Wilck
2024-03-04 15:44       ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 2/7] 10-dm.rules: don't deactivate devices for DISK_RO=1 Martin Wilck
2024-03-04 10:48   ` Peter Rajnoha
2024-03-04 11:19     ` Peter Rajnoha
2024-03-04 11:27       ` Peter Rajnoha
2024-03-04 15:21         ` Martin Wilck
2024-03-04 16:09     ` Martin Wilck
2024-03-05  8:09       ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 3/7] 10-dm-rules: don't restore DM_UDEV_DISABLE_OTHER_RULES_FLAG from db Martin Wilck
2024-03-04 10:49   ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 4/7] 11-dm-lvm.rules: " Martin Wilck
2024-03-04 10:51   ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 5/7] dm udev rules: don't export and save DM_SUSPENDED Martin Wilck
2024-03-04 11:00   ` Peter Rajnoha
2024-03-04 16:21     ` Martin Wilck
2024-03-05  8:19       ` Peter Rajnoha
2024-03-05  8:47         ` Martin Wilck
2024-03-05  9:10           ` Peter Rajnoha
2024-03-05  9:28             ` Martin Wilck
2024-03-01 22:40 ` [RFC PATCH 6/7] dm udev rules: don't export and save DM_NOSCAN Martin Wilck
2024-03-04 11:03   ` Peter Rajnoha
2024-03-01 22:40 ` [RFC PATCH 7/7] 10-dm.rules: bump DM_UDEV_RULES_VSN to 3 Martin Wilck
2024-03-04 11:09   ` Peter Rajnoha
2024-03-04 16:46     ` Martin Wilck
2024-03-05  8:26       ` Peter Rajnoha
2024-03-05  9:04         ` Martin Wilck

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=f82c786b-4b8e-4e5a-a049-bd4cfba668bd@redhat.com \
    --to=prajnoha@redhat.com \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=hare@suse.de \
    --cc=linux-lvm@lists.linux.dev \
    --cc=martin.wilck@suse.com \
    --cc=mwilck@suse.com \
    --cc=teigland@redhat.com \
    --cc=zkabelac@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).