Re: [PATCH 0/2] multipath: Stop extra scans on stacked devices

Re: [PATCH 0/2] multipath: Stop extra scans on stacked devices

[Xose Vazquez Perez]

On 02/12/2014 Benjamin Marzinski wrote:

> Whenever there is a DM_DEVICE_RESUME ioctl, a uevent is generated. Right now,
> when multipath is reloading existing devices do to paths going or coming,
> lvmetad will rescan those devices. This is unnecessary, and can cause a lot
> of overhead. Also, multipath devices with no working paths will get scanned.
> These patches make multipath set a new flag, DM_SUBSYSTEM_UDEV_FLAG0, when it
> is reloading devices due to path changes, and lvmetad can safely ignore it.
> They also add a new udev rules file, 11-dm-mpath.rules, to disable scanning
> when it would not be useful.
> 
> Benjamin Marzinski (2):
>   New udev rules to deal with stacked devices
>   Mark reloads with udev flag
> 
>  Makefile.inc                |  1 +
>  kpartx/devmapper.c          |  4 ++--
>  kpartx/devmapper.h          |  8 +++++++-
>  kpartx/kpartx.c             |  8 ++++----
>  libmultipath/configure.c    |  4 ++--
>  libmultipath/devmapper.c    | 26 ++++++++++++++------------
>  libmultipath/devmapper.h    | 10 ++++++++--
>  multipath/11-dm-mpath.rules | 34 ++++++++++++++++++++++++++++++++++
>  multipath/Makefile          |  3 +++
>  multipathd/cli_handlers.c   |  4 ++--
>  10 files changed, 77 insertions(+), 25 deletions(-)
>  create mode 100644 multipath/11-dm-mpath.rules

This set is missing in git.

Re: [PATCH 0/2] multipath: Stop extra scans on stacked devices

[Christophe Varoqui]

Thanks for the reminder.

This set is applied.


On Tue, Mar 11, 2014 at 5:34 PM, Xose Vazquez Perez
<xose.vazquez@gmail.com> wrote:
> On 02/12/2014 Benjamin Marzinski wrote:
>
>> Whenever there is a DM_DEVICE_RESUME ioctl, a uevent is generated. Right now,
>> when multipath is reloading existing devices do to paths going or coming,
>> lvmetad will rescan those devices. This is unnecessary, and can cause a lot
>> of overhead. Also, multipath devices with no working paths will get scanned.
>> These patches make multipath set a new flag, DM_SUBSYSTEM_UDEV_FLAG0, when it
>> is reloading devices due to path changes, and lvmetad can safely ignore it.
>> They also add a new udev rules file, 11-dm-mpath.rules, to disable scanning
>> when it would not be useful.
>>
>> Benjamin Marzinski (2):
>>   New udev rules to deal with stacked devices
>>   Mark reloads with udev flag
>>
>>  Makefile.inc                |  1 +
>>  kpartx/devmapper.c          |  4 ++--
>>  kpartx/devmapper.h          |  8 +++++++-
>>  kpartx/kpartx.c             |  8 ++++----
>>  libmultipath/configure.c    |  4 ++--
>>  libmultipath/devmapper.c    | 26 ++++++++++++++------------
>>  libmultipath/devmapper.h    | 10 ++++++++--
>>  multipath/11-dm-mpath.rules | 34 ++++++++++++++++++++++++++++++++++
>>  multipath/Makefile          |  3 +++
>>  multipathd/cli_handlers.c   |  4 ++--
>>  10 files changed, 77 insertions(+), 25 deletions(-)
>>  create mode 100644 multipath/11-dm-mpath.rules
>
> This set is missing in git.

kpartx fails 4k block partition

[Ross Anderson]

Greetings,


Under 0.50 multipath tools release, partitions are not being created for 
devices that are 4k Native.  This is under kernel 3.13.6, udev-208.

We've seen this behavior before.

kpartx errors with very little helpful code.

pastebin attached.

Thanks for your assistance.


http://pastebin.com/Nnd4Ym4W

Re: kpartx fails 4k block partition

[Bryn M. Reeves]

On 03/12/2014 10:20 PM, Ross Anderson wrote:
> Under 0.50 multipath tools release, partitions are not being created for
> devices that are 4k Native.  This is under kernel 3.13.6, udev-208.
> 
> http://pastebin.com/Nnd4Ym4W

The devices below don't appear in your lsblk output so it's hard to say
whether the partitions kpartx prints for the devices are valid or not:

>     ##kpartx sfx4k
>     sfx4k1 : 0 2056 sfx4k 2048
>     sfx4k2 : 0 165068760 sfx4k 8192
>     ##kpartx samplelib
>     samplelib1 : 0 2056 samplelib 2048
>     samplelib2 : 0 1171863512 samplelib 8192

That said the tables above look perfectly plausible. It would help to
verify that if you could post the partition tables the devices contain
(preferably in sector units).

> kpartx -a 2 /dev/dm-2
> failed to stat() 2

What's that '2' doing there? The only thing kpartx expects following the
'-a' is the whole disk device:

    SYNOPSIS
       kpartx [-a | -d | -l] [-v] wholedisk

What happens when you run 'kpartx -a /dev/mapper/sfx4k? (or samplelib).

Regards,
Bryn.

Re: kpartx fails 4k block partition *changed**

[Ross Anderson]

Greetings,

I apologize I've riposted a updated pastebin. The dm seemed to have 
become confused with multiple luns being attached and detached before 
this post. A soft reboot of the system re-mapped and produced much 
different results. Now upon start up the 4k devices are not listed under 
lsblk as DM but only as their raw paths. Multipath has created the 
device without partition. I can manually execute kpartx and the dm parts 
are added. So now I'm not sure if this is a multipath problem or udev 
rules.

http://pastebin.com/Nnd4Ym4W

Thanks
Ross


On 3/13/2014 6:01 AM, Bryn M. Reeves wrote:
> On 03/12/2014 10:20 PM, Ross Anderson wrote:
>> Under 0.50 multipath tools release, partitions are not being created for
>> devices that are 4k Native.  This is under kernel 3.13.6, udev-208.
>>
>> http://pastebin.com/Nnd4Ym4W
> The devices below don't appear in your lsblk output so it's hard to say
> whether the partitions kpartx prints for the devices are valid or not:
>
>>      ##kpartx sfx4k
>>      sfx4k1 : 0 2056 sfx4k 2048
>>      sfx4k2 : 0 165068760 sfx4k 8192
>>      ##kpartx samplelib
>>      samplelib1 : 0 2056 samplelib 2048
>>      samplelib2 : 0 1171863512 samplelib 8192
> That said the tables above look perfectly plausible. It would help to
> verify that if you could post the partition tables the devices contain
> (preferably in sector units).
>
>> kpartx -a 2 /dev/dm-2
>> failed to stat() 2
> What's that '2' doing there? The only thing kpartx expects following the
> '-a' is the whole disk device:
>
>      SYNOPSIS
>         kpartx [-a | -d | -l] [-v] wholedisk
>
> What happens when you run 'kpartx -a /dev/mapper/sfx4k? (or samplelib).
>
> Regards,
> Bryn.
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

[PATCH 0/2] multipath: Stop extra scans on stacked devices

[Benjamin Marzinski]

Whenever there is a DM_DEVICE_RESUME ioctl, a uevent is generated. Right now,
when multipath is reloading existing devices do to paths going or coming,
lvmetad will rescan those devices. This is unnecessary, and can cause a lot
of overhead. Also, multipath devices with no working paths will get scanned.
These patches make multipath set a new flag, DM_SUBSYSTEM_UDEV_FLAG0, when it
is reloading devices due to path changes, and lvmetad can safely ignore it.
They also add a new udev rules file, 11-dm-mpath.rules, to disable scanning
when it would not be useful.

Benjamin Marzinski (2):
  New udev rules to deal with stacked devices
  Mark reloads with udev flag

 Makefile.inc                |  1 +
 kpartx/devmapper.c          |  4 ++--
 kpartx/devmapper.h          |  8 +++++++-
 kpartx/kpartx.c             |  8 ++++----
 libmultipath/configure.c    |  4 ++--
 libmultipath/devmapper.c    | 26 ++++++++++++++------------
 libmultipath/devmapper.h    | 10 ++++++++--
 multipath/11-dm-mpath.rules | 34 ++++++++++++++++++++++++++++++++++
 multipath/Makefile          |  3 +++
 multipathd/cli_handlers.c   |  4 ++--
 10 files changed, 77 insertions(+), 25 deletions(-)
 create mode 100644 multipath/11-dm-mpath.rules

-- 
1.8.4.2