Hello Martin,
This exmaple shows why we need to stop merging,
Yes, It's fine since we have "stop merging" in current code.
RegardsTang
原始邮件
发件人： ＜mwi...@suse.com＞
收件人： ＜dm-devel@redhat.com＞
日 期 ：2017年02月20日 19:24
主 题 ：Re: [dm-devel] 答复: Re: [PATCH] multipath-tools: impro
On Wed, Feb 15, 2017 at 06:56:17AM -0800, Christoph Hellwig wrote:
> On Tue, Feb 14, 2017 at 04:19:13PM -0500, Keith Busch wrote:
> > These devices are mulitpath capable, and have been able to stack with
> > dm-mpath since kernel 4.2.
>
> Can we make this conditional on something? I have native N
On Tue, Feb 14, 2017 at 04:19:14PM -0500, Keith Busch wrote:
> Signed-off-by: Keith Busch
> ---
> Pat of this is dependent on udev updates. Pull request sent to systemd here:
>
> https://github.com/systemd/systemd/pull/5348
>
> Can always add that line by hand in the mean time.
>
> libmultip
On Tue, Feb 14 2017 at 4:19pm -0500,
Keith Busch wrote:
> These devices are mulitpath capable, and have been able to stack with
> dm-mpath since kernel 4.2.
>
> Signed-off-by: Keith Busch
> ---
> libmultipath/blacklist.c | 2 +-
> multipath/multipath.conf.5 | 2 +-
> 2 files changed, 2 inse
Cc: Bart Van Assche
Cc: Christophe Varoqui
Cc: device-mapper development
Signed-off-by: Xose Vazquez Perez
---
third-party/valgrind/valgrind.h | 40 +---
1 file changed, 37 insertions(+), 3 deletions(-)
diff --git a/third-party/valgrind/valgrind.h b/third-p
On 02/19/2017 01:46 PM, Gilad Ben-Yossef wrote:
> Use of the synchronous digest API limits dm-verity to using pure
> CPU based algorithm providers and rules out the use of off CPU
> algorithm providers which are normally asynchronous by nature,
> potentially freeing CPU cycles.
>
> This can reduce
Hi Ben,
On Tue, 2017-02-14 at 20:16 -0600, Benjamin Marzinski wrote:
> This patch adds a detect_checker option that works just like the
> detect_prio option.
This one doesn't apply cleanly on top of upstream, probably because you
were missing Muneendra's patch c3705a12.
The result of my local m
Hello Tang,
＞ In the second case, we know all events in the sequence have the
> same
> ＞ WWID; in this case I think it would be safe to filter away "remove"
> ＞ events by subsequent "add" events, ending up with "add path1| add
> ＞ path2| remove path3". But I may be overlooking something here.
>
>
