Fixes: 22736419 "kpartx.rules: respect skip_kpartx flag"
Signed-off-by: Martin Wilck
---
kpartx/kpartx.rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kpartx/kpartx.rules b/kpartx/kpartx.rules
index a9587917..64d550de 100644
--- a/kpartx/kpartx.rules
and the 'MD Series' comment to the right place.
Cc: Christophe Varoqui
Cc: device-mapper development
Signed-off-by: Xose Vazquez Perez
---
libmultipath/hwtable.c | 98
On 06/22/2017 04:59 PM, Martin Wilck wrote:
> Kernels 4.3 and newer (commit 1bab0de0 "dm-mpath, scsi_dh: don't
> let dm detach device handlers") imply "retain_attached_hw_handler yes".
>
> Clarify this in the propsel code, log messages, and documentation.
>
> Signed-off-by: Martin Wilck
On 06/22/2017 06:59 PM, Bart Van Assche wrote:
> Why do you think this kind of changes is useful? Are you aware that
> whitespace-only changes are very annoying to anyone else who is preparing
> changes on the same file because such changes result in a huge number of
> annoying rebase conflicts?
From: Heinz Mauelshagen
When a RAID set was created on dm-raid version < 1.9.0
(old RAID superblock format), none of the new members of the
superblock have been set including the device sectors member
needed to support shrinking.
Don't access such member unconditionally.
Add
On Thu, May 18, 2017 at 01:40:38PM +0200, Ondrej Mosnacek wrote:
>
> > Actually I think this one can probably easily handled in the crypto
> > layer. All we need is to add a multikey template that sits on top
> > of an underlying IV generator. The multikey instance can then accept
> > a key
Binoy Jayan wrote:
> ===
> dm-crypt optimization for larger block sizes
> ===
>
> Currently, the iv generation