Re: [dm-devel] [PATCH 04/21] libmultipath: never allocate an alias that's already taken

2023-09-07 Thread Martin Wilck
On Thu, 2023-09-07 at 15:33 +0200, Martin Wilck wrote: > On Thu, 2023-09-07 at 09:24 +0200, Martin Wilck wrote: > > On Wed, 2023-09-06 at 17:42 -0500, Benjamin Marzinski wrote: > > > On Fri, Sep 01, 2023 at 08:02:17PM +0200, mwi...@suse.com wrote: > > > > > > > > > Again, unless I'm overlooking

Re: [dm-devel] [PATCH 04/21] libmultipath: never allocate an alias that's already taken

2023-09-07 Thread Martin Wilck
On Thu, 2023-09-07 at 09:24 +0200, Martin Wilck wrote: > On Wed, 2023-09-06 at 17:42 -0500, Benjamin Marzinski wrote: > > On Fri, Sep 01, 2023 at 08:02:17PM +0200, mwi...@suse.com wrote: > > > > > > Again, unless I'm overlooking something, I don't think we need to > > check if the alias is

Re: [dm-devel] [PATCH 04/21] libmultipath: never allocate an alias that's already taken

2023-09-07 Thread Martin Wilck
On Wed, 2023-09-06 at 17:42 -0500, Benjamin Marzinski wrote: > On Fri, Sep 01, 2023 at 08:02:17PM +0200, mwi...@suse.com wrote: > > From: Martin Wilck > > > > If the bindings file is changed in a way that multipathd can't > > handle > > (e.g. by swapping the aliases of two maps), multipathd must

Re: [dm-devel] [PATCH 04/21] libmultipath: never allocate an alias that's already taken

2023-09-06 Thread Benjamin Marzinski
On Fri, Sep 01, 2023 at 08:02:17PM +0200, mwi...@suse.com wrote: > From: Martin Wilck > > If the bindings file is changed in a way that multipathd can't handle > (e.g. by swapping the aliases of two maps), multipathd must not try > to re-use an alias that is already used by another map. Creating

[dm-devel] [PATCH 04/21] libmultipath: never allocate an alias that's already taken

2023-09-01 Thread mwilck
From: Martin Wilck If the bindings file is changed in a way that multipathd can't handle (e.g. by swapping the aliases of two maps), multipathd must not try to re-use an alias that is already used by another map. Creating or renaming a map with such an alias will fail. We already avoid this for