Re: [dm-devel] [PATCH v5 20/22] multipath -u: test if path is busy

On Sat, Apr 14, 2018 at 12:00:13AM +0200, Martin Wilck wrote: > For "find_multipaths smart", check if a path is already in use > before setting DM_MULTIPATH_DEVICE_PATH to 1 or 2 (and thus, > SYSTEMD_READY=0). If we don't do this, a device which has already been > mounted (e.g. during initrd

[dm-devel] [patch 2/2] dm-delay: add third flush class

This patch adds a new class for dm-delay that delays flush requests. Previously, flushes were delayed as writes, but it caused problems if the user needed to create a device with one or few slow sectors for the purpose of testing - all flushes would be forwarded to this device and delayed, and

[dm-devel] [patch 1/2] dm-delay: refactor repetitive code

dm-delay has a lot of code that is repeated for delaying read and write bios. Repetitive code is generally bad; I intend to add another class for flush bios, so I refactor out the repetitive code, so that the new class can be added easily. Signed-off-by: Mikulas Patocka ---

[dm-devel] [patch 0/2] dm-delay flush patches

Hi These patches extend dm-delay, so that the user can select separate delay for flush requests. Zdenek needs to create a device with one slow sector for the purpose of testing, so he creates a device that has three targets: linear,delay,linear The problem with this setup is that flushes are

Re: [dm-devel] [PATCH v5 19/22] multipath -u: don't grab devices already passed to system

On Sat, Apr 14, 2018 at 12:00:12AM +0200, Martin Wilck wrote: > Setting SYSTEMD_READY=0 on a device that has previously been passed to > systemd is dangerous - already mounted file systems might be unmounted by > systemd. > > Avoid that by checking for previously set DM_MULTIPATH_DEVICE_PATH >

Re: [dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Mon, 16 Apr 2018, Vlastimil Babka wrote: > On 04/13/2018 05:10 PM, Mike Snitzer wrote: > > On Fri, Apr 13 2018 at 5:22am -0400, > > Vlastimil Babka wrote: > >> > >> Would this perhaps be a good LSF/MM discussion topic? Mikulas, are you > >> attending, or anyone else that

Re: [dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Mon, 16 Apr 2018, Vlastimil Babka wrote: > On 04/16/2018 09:36 PM, Mikulas Patocka wrote: > > >>> I need to increase it just for dm-bufio slabs. > >> > >> If you do this then others will want the same... > > > > If others need it, they can turn on the flag SLAB_MINIMIZE_WASTE too. > > I

Re: [dm-devel] [PATCH v5 17/22] multipath -u: cleanup logic

On Sat, Apr 14, 2018 at 12:00:10AM +0200, Martin Wilck wrote: > The CMD_VALID_PATH logic is complex and hard to read and understand. > This patch cleans it up a bit (preparing for folluw-up patches). > It doesn't change any logic. > Reviewed-by: Benjamin Marzinski >

Re: [dm-devel] [PATCH v5 16/22] multipath -u : set FIND_MULTIPATHS_WAIT_UNTIL from /dev/shm

On Sat, Apr 14, 2018 at 12:00:09AM +0200, Martin Wilck wrote: > In "find_multipaths smart" mode, use time stamps under > /dev/shm/multipath/find_multipaths to track waiting for multipath > siblings. When a path is first encountered and is "maybe" multipath, create > a file under /dev/shm, set its

Re: [dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Mon, 16 Apr 2018, Christopher Lameter wrote: > On Mon, 16 Apr 2018, Mikulas Patocka wrote: > > > > > > > Or an increase in slab_max_order > > > > But that will increase it for all slabs (often senselessly - i.e. > > kmalloc-4096 would have order 4MB). > > 4MB? Nope That is a power of

[dm-devel] [PATCH RESEND] slab: introduce the flag SLAB_MINIMIZE_WASTE

This patch introduces a flag SLAB_MINIMIZE_WASTE for slab and slub. This flag causes allocation of larger slab caches in order to minimize wasted space. This is needed because we want to use dm-bufio for deduplication index and there are existing installations with non-power-of-two block sizes

[dm-devel] [PATCH RESEND 2/2] lvm2: 69-dm-lvm-metad.rules: set systemd vars on "change"

The current logic that avoids setting SYSTEMD_ALIAS and SYSTEMD_WANTS on "change" events is flawed in the default "systemd background job" configuration. For systemd, it's important that device properties don't change spuriously. If an "add" event starts lvm2-pvscan@.service for a device, and a

[dm-devel] [PATCH RESEND 1/2] lvm2: 69-dm-lvm-metad.rules: explicit pvscan rule

Make the distinction between the cases with and without systemd background jobs explicit in 69-dm-lvm-metad.rules rather than substituting the rule from the Makefile. At this stage, this improves only readibility, at the cost of one GOTO statement. The next patch will add more differences between

[dm-devel] [PATCH RESEND 0/2] LVM2: fix lvmetad udev rules for CHANGE events

(This has been sent to lvm-devel on Dec 21, 2017, and apparently got lost. Resending). The current logic in 69-dm-lvm-metad.rules is broken for the default "enable-udev-systemd-background-jobs" case. Detailed information about the problem can be found in the commit message of the 2nd patch in the

Re: [dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Mon, 16 Apr 2018, Mikulas Patocka wrote: > > > > Or an increase in slab_max_order > > But that will increase it for all slabs (often senselessly - i.e. > kmalloc-4096 would have order 4MB). 4MB? Nope That is a power of two slab so no wasted space even with order 0. Its not a senseless

Re: [dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Mon, 16 Apr 2018, Christopher Lameter wrote: > On Mon, 16 Apr 2018, Mikulas Patocka wrote: > > > > Please clarify further, thanks! > > > Mike > > > > Yes, using a slab cache currently doesn't avoid this rouding (it needs the > > SLAB_MINIMIZE_WASTE patch to do that). > > Or an increase in

Re: [dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Mon, 16 Apr 2018, Mikulas Patocka wrote: > > Please clarify further, thanks! > > Mike > > Yes, using a slab cache currently doesn't avoid this rouding (it needs the > SLAB_MINIMIZE_WASTE patch to do that). Or an increase in slab_max_order -- dm-devel mailing list dm-devel@redhat.com

Re: [dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Mon, 16 Apr 2018, Mike Snitzer wrote: > On Mon, Apr 16 2018 at 10:37am -0400, > Mikulas Patocka wrote: > > > > > > > On Mon, 16 Apr 2018, Mike Snitzer wrote: > > > > > On Mon, Apr 16 2018 at 8:38am -0400, > > > Vlastimil Babka wrote: > > > > > > >

Re: [dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Mon, Apr 16 2018 at 10:37am -0400, Mikulas Patocka wrote: > > > On Mon, 16 Apr 2018, Mike Snitzer wrote: > > > On Mon, Apr 16 2018 at 8:38am -0400, > > Vlastimil Babka wrote: > > > > > On 04/13/2018 05:10 PM, Mike Snitzer wrote: > > > > On Fri, Apr

Re: [dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Mon, 16 Apr 2018, Mike Snitzer wrote: > On Mon, Apr 16 2018 at 8:38am -0400, > Vlastimil Babka wrote: > > > On 04/13/2018 05:10 PM, Mike Snitzer wrote: > > > On Fri, Apr 13 2018 at 5:22am -0400, > > > Vlastimil Babka wrote: > > >> > > >> Would this

Re: [dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

On Mon, Apr 16 2018 at 8:38am -0400, Vlastimil Babka wrote: > On 04/13/2018 05:10 PM, Mike Snitzer wrote: > > On Fri, Apr 13 2018 at 5:22am -0400, > > Vlastimil Babka wrote: > >> > >> Would this perhaps be a good LSF/MM discussion topic? Mikulas, are you > >>

Re: [dm-devel] slab: introduce the flag SLAB_MINIMIZE_WASTE

On 04/13/2018 05:10 PM, Mike Snitzer wrote: > On Fri, Apr 13 2018 at 5:22am -0400, > Vlastimil Babka wrote: >> >> Would this perhaps be a good LSF/MM discussion topic? Mikulas, are you >> attending, or anyone else that can vouch for your usecase? > > Any further discussion on

Re: [dm-devel] [PATCH v5 20/22] multipath -u: test if path is busy

On Mon, 2018-04-16 at 08:32 +0200, Hannes Reinecke wrote: > > But doesn't this cause udev to generate another event upon release? > Or is that prevented by the O_RDONLY setting? Exactly, udev triggers only on "close after write" events. Martin -- Dr. Martin Wilck , Tel. +49

[dm-devel] Patch added to scsi: scsi: scsi_dh: replace too broad "TP9" string with the exact models

Your commit: scsi: scsi_dh: replace too broad "TP9" string with the exact models SGI/TP9100 is not an RDAC array: ^^^ https://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=libmultipath/hwtable.c;h=88b4700beb1d8940008020fbe4c3cd97d62f4a56;hb=HEAD#l235

Re: [dm-devel] [PATCH v5 22/22] multipath.rules: find_multipaths "smart" logic

On Sat, 14 Apr 2018 00:00:15 +0200 Martin Wilck wrote: > When the first path to a device appears, we don't know if more paths > are going to follow. find_multipath "smart" logic attempts to solve > this dilemma by waiting for additional paths for a configurable time > before

Re: [dm-devel] [PATCH v5 21/22] libmultipath: enable find_multipaths "smart"

On Sat, 14 Apr 2018 00:00:14 +0200 Martin Wilck wrote: > This activates "smart" path detection. This is similar to > "find_multipaths yes", but doesn't generally ignore single paths > that are not listed in the WWIDs file. Rather, such paths are > temporarily treated like

Re: [dm-devel] [PATCH v5 20/22] multipath -u: test if path is busy

On Sat, 14 Apr 2018 00:00:13 +0200 Martin Wilck wrote: > For "find_multipaths smart", check if a path is already in use > before setting DM_MULTIPATH_DEVICE_PATH to 1 or 2 (and thus, > SYSTEMD_READY=0). If we don't do this, a device which has already been > mounted (e.g. during

Re: [dm-devel] [PATCH v5 19/22] multipath -u: don't grab devices already passed to system

On Sat, 14 Apr 2018 00:00:12 +0200 Martin Wilck wrote: > Setting SYSTEMD_READY=0 on a device that has previously been passed to > systemd is dangerous - already mounted file systems might be > unmounted by systemd. > > Avoid that by checking for previously set

Re: [dm-devel] [PATCH v5 18/22] multipath -u: quick check if path is multipathed

On Sat, 14 Apr 2018 00:00:11 +0200 Martin Wilck wrote: > With "find_multipaths smart", we accept paths as valid if they are > already part of a multipath map. This patch avoids doing a full path > and device-mapper map scan for this case, speeding up "multipath -u" >

Re: [dm-devel] [PATCH v5 17/22] multipath -u: cleanup logic

On Sat, 14 Apr 2018 00:00:10 +0200 Martin Wilck wrote: > The CMD_VALID_PATH logic is complex and hard to read and understand. > This patch cleans it up a bit (preparing for folluw-up patches). > It doesn't change any logic. > > Signed-off-by: Martin Wilck >

Re: [dm-devel] [PATCH v5 16/22] multipath -u : set FIND_MULTIPATHS_WAIT_UNTIL from /dev/shm

On Sat, 14 Apr 2018 00:00:09 +0200 Martin Wilck wrote: > In "find_multipaths smart" mode, use time stamps under > /dev/shm/multipath/find_multipaths to track waiting for multipath > siblings. When a path is first encountered and is "maybe" multipath, > create a file under

Re: [dm-devel] [PATCH v5 15/22] libmultipath: implement find_multipaths_timeout

On Sat, 14 Apr 2018 00:00:08 +0200 Martin Wilck wrote: > This makes the timeout for "find_multipaths smart" configurable. > If the timeout has a negative value (default), it's applied only > to "known" hardware which is either in the hwtable or in a "device" > section in

Re: [dm-devel] [PATCH v5 13/22] multipath -u: treat failed wwids as invalid

On Sat, 14 Apr 2018 00:00:06 +0200 Martin Wilck wrote: > If a WWID has been marked as "failed", don't treat it as "valid > multipath device path" in multipath -c/-u. This is key to achieve > consistency between multipathd and udev rule processing. > > Signed-off-by: Martin

Re: [dm-devel] [PATCH v5 14/22] multipath -u: add DM_MULTIPATH_DEVICE_PATH=2 for "maybe"

On Sat, 14 Apr 2018 00:00:07 +0200 Martin Wilck wrote: > Use DM_MULTIPATH_DEVICE_PATH="2" to indicate that this might be a > valid path, but we aren't certain. This happens with find_multipaths > "smart", when the first path to a device (or a single-path > device) is

Re: [dm-devel] [PATCH v5 12/22] multipath -u: change output to environment/key format

On Sat, 14 Apr 2018 00:00:05 +0200 Martin Wilck wrote: > ... instead of free format. This provides more flexibility > for udev rule processing for the future. Adapt code in > multipath.rules. The exit status remains as usual. This affects > "multipath -c", too. > > The

Re: [dm-devel] [PATCH v5 11/22] multipath -u: common code path for result message

On Sat, 14 Apr 2018 00:00:04 +0200 Martin Wilck wrote: > Print the result message in one place only. This simplifies > future changes. multipath -c is also affected. > > Signed-off-by: Martin Wilck > Reviewed-by: Benjamin Marzinski > ---

Re: [dm-devel] [PATCH v5 10/22] libmultipath: indicate wwid failure in dm_addmap_create()

On Sat, 14 Apr 2018 00:00:03 +0200 Martin Wilck wrote: > dm_addmap_create() is where we actually try to set up a new > multipath map. Depending on the result, mark the wwid as > failed (or not), and re-trigger an uevent if necessary. > If a path changes from multipath to

Re: [dm-devel] [PATCH v5 09/22] libmultipath: functions to indicate mapping failure in /dev/shm

On Sat, 14 Apr 2018 00:00:02 +0200 Martin Wilck wrote: > Create a simple API that indicates failure to create a map for a > certain WWID. This will allow multipathd to indicate to other tools > (in particular, "multipath -u" during udev processing) that > an attempt to create a

Re: [dm-devel] [PATCH v5 08/22] libmultipath: use const char* in open_file()

On Sat, 14 Apr 2018 00:00:01 +0200 Martin Wilck wrote: > Reviewed-by: Benjamin Marzinski > Signed-off-by: Martin Wilck > --- > libmultipath/file.c | 6 +++--- > libmultipath/file.h | 2 +- > 2 files changed, 4 insertions(+), 4

Re: [dm-devel] [PATCH v5 07/22] libmultipath: change find_multipaths option to multi-value

On Sat, 14 Apr 2018 00:00:00 +0200 Martin Wilck wrote: > Change the "find_multipaths" option from yes/no to multi-value. This > option now covers the effects of "find_multipaths" as it used to be, > plus the -i option to multipath (ignore_wwids) and the -n option to > multipathd

Re: [dm-devel] [PATCH v5 06/22] libmultipath: trigger path uevent only when necessary

On Fri, 13 Apr 2018 23:59:59 +0200 Martin Wilck wrote: > Paths that are already classified as DM_MULTIPATH_DEVICE_PATH don't > need to be retriggered. > > Reviewed-by: Benjamin Marzinski > Signed-off-by: Martin Wilck > --- >

Re: [dm-devel] [PATCH v5 05/22] libmultipath: trigger change uevent on new device creation

On Fri, 13 Apr 2018 23:59:58 +0200 Martin Wilck wrote: > From: Benjamin Marzinski > > When multipath first sees a path device with find_multipaths > enabled, it can't know if the device should be multipathed. This means > that it will not claim the device

Re: [dm-devel] [PATCH v5 04/22] multipath -u -i: respect entries in WWIDs file

On Fri, 13 Apr 2018 23:59:57 +0200 Martin Wilck wrote: > Previously, if find_multipaths was set, devices listed in the WWIDs > file weren't classified as multipath members by "multipath -u -i" > unless they also met the "find_multipaths" criteria (at least two > paths, or

Re: [dm-devel] [PATCH v5 03/22] libmultipath: should_multipath: keep existing maps

On Fri, 13 Apr 2018 23:59:56 +0200 Martin Wilck wrote: > with find_multipaths "yes" and without the "-n" option to multipathd, > if a path is already multipathed, keep it. The same logic is applied > by "multipath -u -i". > > To do this, we need to add a "mpvec" parameter to

Re: [dm-devel] [PATCH v5 02/22] Revert "multipathd: imply -n if find_multipaths is set"

On Fri, 13 Apr 2018 23:59:55 +0200 Martin Wilck wrote: > This reverts commit 64e27ec066a001012f44550f095c93443e91d845. > > Reviewed-by: Benjamin Marzinski > Signed-off-by: Martin Wilck > --- > multipathd/main.c | 4 > 1 file

Re: [dm-devel] [PATCH v5 01/22] Revert "multipath: ignore -i if find_multipaths is set"

On Fri, 13 Apr 2018 23:59:54 +0200 Martin Wilck wrote: > This reverts commit ffbb886a8a16cb063d669cd76a1e656fd3ec8c4b. > > Reviewed-by: Benjamin Marzinski > Signed-off-by: Martin Wilck > --- > multipath/main.c | 10 -- > 1 file