On this thread:
https://www.spinics.net/lists/dm-devel/msg31991.html
I saw a strawman proposal for using nvdimm in other kernel modules: i.e.
using ->direct_access()
I am wondering if anyone else is utilizing nvram from kernel modules,
and if so, what advice you might have, including what
On Sun, Sep 03, 2017 at 12:38:29AM +0200, Martin Wilck wrote:
> The main part of this series is a cleanup of the udev rules for
> multipath and kpartx. More about that further down.
>
> - patch 01 is an obvious bug fix
> - patch 02-08 are fixes for kpartx problems that I encountered
>during
On Sun, Sep 03, 2017 at 12:38:59AM +0200, Martin Wilck wrote:
> A new udev rules file "68-del-part-nodes.rules" is introduced,
> based on code from Ben Marzinki. This code deletes partitions on
> multipath member devices. The purpose of this is to avoid users
> accidentally accessing partitions of
On Sun, Sep 03, 2017 at 12:39:00AM +0200, Martin Wilck wrote:
> Current kpartx.rules combines two purposes: setting properties and
> creating symlinks for dm partition devices, and creating such
> partition devices on top of other devices. This is contrary to
> common conventions for udev rules fil
On Sun, Sep 03, 2017 at 12:38:49AM +0200, Martin Wilck wrote:
> The fact alone that a map changes from not ready to ready does
> not imply that it is activating.
NAK on this one and
[PATCH 21/31] 11-dm-mpath.rules: Remember DM_ACTIVATION
This breaks things. It's often the case that there are devi
On Wed, 2017-09-13 at 16:19 -0500, Benjamin Marzinski wrote:
> On Sun, Sep 03, 2017 at 12:38:49AM +0200, Martin Wilck wrote:
> > The fact alone that a map changes from not ready to ready does
> > not imply that it is activating.
>
> NAK on this one and
> [PATCH 21/31] 11-dm-mpath.rules: Remember D
On Sun, Sep 03, 2017 at 12:38:50AM +0200, Martin Wilck wrote:
> If DM_ACTIVATION is set by the general dm rules, we need to
> bring up this device. But if the mpath device is not ready,
> that would be dangerous; it could hang or produce lots of IO
> errors. So remember this state, and try to activ
On Sun, Sep 03, 2017 at 12:38:44AM +0200, Martin Wilck wrote:
> When we process udev rules, it's crucial to know whether I/O on a given
> device will succeed. Unfortunately DM_NR_VALID_PATHS is not reliable,
> because the kernel path events aren't necessarily received in order, and
> even if they a
On Sun, Sep 03, 2017 at 12:38:38AM +0200, Martin Wilck wrote:
> Some vendor kernels (e.g. SUSE) have supported loading multipath
> maps without valid paths for a long time. Without that feature,
> problems can occur in failover scenarios when multipathd tries
> to (re)load maps after device failure
On 02/21/2017 11:12 PM, Keith Busch wrote:
> diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c
> index f5a5f7b..8409261 100644
> --- a/libmultipath/hwtable.c
> +++ b/libmultipath/hwtable.c
> @@ -1073,6 +1073,16 @@ static struct hwentry default_hw[] = {
> .prio_name = P
On 09/08/2017 08:45 PM, Benjamin Marzinski wrote:
> There are also new multipathd commands to get, set, and unset the
> mappings in the prkesy file. Currently,
>
> "multipathd map $map setprkey key $key" sets the mapping
> "multipathd map $map unsetprkey" unsets the mapping
> "multipathd map $map
If a crypt mapping uses optional sector_size feature, additional
restrictions to mapped device segment size must be applied in constructor,
otherwise the device activation will fail later.
Signed-off-by: Milan Broz
---
drivers/md/dm-crypt.c | 4
1 file changed, 4 insertions(+)
diff --git a
12 matches
Mail list logo
