linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: "linux-lvm@lists.linux.dev" <linux-lvm@lists.linux.dev>
Subject: Re: discuss about commit 3b0f9ce: filter-mpath: get wwids from sysfs vpd_pg83
Date: Thu, 16 Nov 2023 16:59:45 +0100	[thread overview]
Message-ID: <aaa81c84-55a2-4d2e-8368-16571bd3dd7a@redhat.com> (raw)
In-Reply-To: <ZVYw9eNTj7Ir6V31@redhat.com>

Dne 16. 11. 23 v 16:10 David Teigland napsal(a):
> On Thu, Nov 16, 2023 at 02:37:13PM +0100, Zdenek Kabelac wrote:
>>> and restore define DEFAULT_USE_DEVICES_FILE 1.
>> There is no problem with configuring DEFAULT_USE_DEVICES_FILE with
>> 'configure --with-default-use-devices-file= 0/1' and thus no need to change
>> anything here.
>>
>> Current upstream has set this default value as 0  (in configure.ac)
> I didn't realize you'd changed the default, please set it back to 1.
> (Even better put back DEFAULT_USE_DEVICES_FILE; configured settings
> are a pain to deal with, and the complexity causes real problems.)

configure is the right way how to set 'default' parameter for compilation.

And since different distribution needs different defaults - it's way better 
then letting every distro maintain some patch sets separately.

Even i.e. building of RHEL8 and RHEL9 have different defaults.

Once the option become supported properly across wide distribution set  - it's 
very easy to flip default in 'configure.ac'  from 0 to 1.

There is no need to change anything else here.

RHEL & Fedora builds are prepared and use proper configure set and build 
proper packages

>> The major problem with turning this  to 1 is the distribution must be
>> 'ready' with such relatively invasive change as it changes also requirements
>> on how the boot image is created  (devicesfile must be copied to ramdisk).
> While a distribution does want to be aware of the change (discussed
> earlier in the thread), what you're saying specifically is not true.
> RHEL, which has this enabled, doesn't even have system.devices in the
> ramdisk.  It simply means that it's not used for activating the root LV.
>

Since lvm2  without 'devicesfiles' will fallback to filters, which by default 
accept 'every' device, this in most cases  will lead to the situation,  that 
if there are no 'specific' needs to filter something out  usually the right LV 
will be activated.

So in most cases even if the 'devicesfile' is not being copied it will appear 
like it's working.

But there will be situation where the systems where lvm2  will be accessing 
devices it should not access - and this is a problem that should be addressed 
(i.e. duplicate devices present in the system).


Zdenek



  parent reply	other threads:[~2023-11-16 15:59 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-11 12:51 discuss about commit 3b0f9ce: filter-mpath: get wwids from sysfs vpd_pg83 Heming Zhao
2023-11-13 11:52 ` Martin Wilck
2023-11-13 13:52   ` Peter Rajnoha
2023-11-13 18:38     ` David Teigland
2023-11-14  7:55       ` Peter Rajnoha
2023-11-14 16:30         ` David Teigland
2023-11-15  8:51           ` Peter Rajnoha
2023-11-15 11:36             ` Heming Zhao
2023-11-15 19:12               ` David Teigland
2023-11-16 13:37                 ` Zdenek Kabelac
2023-11-16 13:46                   ` Martin Wilck
2023-11-16 14:03                     ` Zdenek Kabelac
2023-11-16 15:29                       ` Martin Wilck
2023-11-16 17:13                         ` David Teigland
2023-11-16 15:10                   ` David Teigland
2023-11-16 15:40                     ` Martin Wilck
2023-11-16 15:48                       ` Zdenek Kabelac
2023-11-16 17:27                         ` David Teigland
2023-11-16 15:59                     ` Zdenek Kabelac [this message]
2023-11-17  1:47                   ` Demi Marie Obenour
2023-11-17 15:25                     ` David Teigland
2023-11-17 19:57                       ` Demi Marie Obenour
2023-11-17 20:16                         ` David Teigland
2023-11-17 21:03                           ` Demi Marie Obenour
2023-11-17 21:05                             ` Martin Wilck
2023-11-20 10:13                               ` Zdenek Kabelac
2023-11-15 21:02             ` David Teigland
2023-11-15 21:46               ` Martin Wilck
2023-11-16 16:11                 ` David Teigland
2023-11-14 10:44       ` Martin Wilck
2023-11-14 12:18         ` Heming Zhao
2023-11-14 17:16           ` David Teigland
2023-11-14 17:00         ` David Teigland
2023-11-14 17:48           ` Martin Wilck
2023-11-14 17:58             ` Martin Wilck
2023-11-14 21:02               ` David Teigland
2023-11-15  7:35                 ` Martin Wilck
2023-11-16 16:34                   ` David Teigland
2023-11-16 20:22                     ` Benjamin Marzinski
2023-11-14 20:51             ` David Teigland
2023-11-15  5:15               ` Heming Zhao
2023-11-15  7:39                 ` Martin Wilck
2023-11-21 14:39   ` Martin Wilck
2023-11-21 17:56     ` David Teigland
2023-11-21 18:10       ` Martin Wilck
2023-11-21 18:25         ` David Teigland
2023-11-21 20:35           ` 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=aaa81c84-55a2-4d2e-8368-16571bd3dd7a@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=linux-lvm@lists.linux.dev \
    /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).