Hello Ben,
I know the issue of socket's buffer fills up,
but I think uevent_can_discard() totally process in memory,
it is light-weight and low cpu consumption, and it reduce the
iteration count in merging, the test result is also good in
massive multipath devices scene.
But if you still stick
Hello Ben,
> Right now, multipath users are allowed configure devices to set the wwid
> based on any udev environment variable (or even use a callout, although
> this is deprecated). With this patch, that breaks.
Does WWID obtained by different methods change? If it changes, we would
better to mo
On Tue, Jan 03 2017, Jack Wang wrote:
> 2016-12-23 12:45 GMT+01:00 Lars Ellenberg :
>> On Fri, Dec 23, 2016 at 09:49:53AM +0100, Michael Wang wrote:
>>> Dear Maintainers
>>>
>>> I'd like to ask for the status of this patch since we hit the
>>> issue too during our testing on md raid1.
>>>
>>> Spli
Hello Ben,
Yes, a *_safe list traversal method can meet the needs,
I will modify it and simplify the codes.
Thanks,
Tang Junhui
发件人: "Benjamin Marzinski"
收件人: tang.jun...@zte.com.cn,
抄送: tang.wenj...@zte.com.cn, zhang.ka...@zte.com.cn,
dm-devel@redhat.com, bart.vanass...@
Hello Ben,
I add wwid judgment for safe.
I think twice, and as you say, it is safe enough without
this judgment, I will delete these wwid judgment.
Tanks
Tang Junhui
发件人: "Benjamin Marzinski"
收件人: tang.jun...@zte.com.cn,
抄送: tang.wenj...@zte.com.cn, zhang.ka...@zte.com.cn,
Hello Ben
Good idea,
I will modify the patch to filter these change uevents.
Thanks
Tang Junhui
发件人: "Benjamin Marzinski"
收件人: tang.jun...@zte.com.cn,
抄送: tang.wenj...@zte.com.cn, zhang.ka...@zte.com.cn,
dm-devel@redhat.com, bart.vanass...@sandisk.com, mwi...@suse.com
日期:
On Tue, Dec 27, 2016 at 04:03:27PM +0800, tang.jun...@zte.com.cn wrote:
> From: tang.junhui
>
> Before merging uevents, these uevents are going to be filtered:
> Change or addition uevent of a removed path (it indicate by an
> deletion uevent occurred later).
>
I think it's safe to remove add a
On Tue, Dec 27, 2016 at 04:03:28PM +0800, tang.jun...@zte.com.cn wrote:
> From: "tang.junhui"
>
> After filtering and merging, then uevents are processed in
> uev_trigger(), firstly, each of merged uevents would be processed one
> by one with need_do_map in value of 0. Finally, the node “uev” its
On Tue, Dec 27, 2016 at 04:03:26PM +0800, tang.jun...@zte.com.cn wrote:
> From: tang.junhui
>
> These uevents are going to be merged:
> 1) uevents come from paths and
> 2) uevents type is same and
> 3) uevents type is addition or deletion and
> 4) uevents wwid is same.
This is just a nit, and I
On Tue, Dec 27, 2016 at 04:03:25PM +0800, tang.jun...@zte.com.cn wrote:
> From: tang.junhui
>
> The more uevents are merged, the higher efficiency program will performs.
> So, do not process uevents after receiving immediately in uevents burst
> situations, but continue wait 1 seconds for more ue
On Tue, Dec 27, 2016 at 04:03:18PM +0800, tang.jun...@zte.com.cn wrote:
> From: tang.junhui
>
> Add "char *wwid" to point WWID of uevent. This member identifies
> the LUN ID which the path belongs to, and it is used for merging
> uevents. WWID possibly did not exist in uevent yet, so ->wwid
> wou
On Thu, Dec 29, 2016 at 03:56:14PM +0800, tang.jun...@zte.com.cn wrote:
> From: "tang.junhui"
>
> SIGUSR2 is not blocked by default, it would cause bellow conflict
> in removing of the last path:
ACK
-Ben
> -
> uevent processing threa
On Mon, Dec 26, 2016 at 09:42:48AM +, Muneendra Kumar M wrote:
> Hi Ben,
>
> If there are two paths on a dm-1 say sda and sdb as below.
>
> # multipath -ll
> mpathd (3600110d001ee7f0102050001cc0b6751) dm-1 SANBlaze,VLUN MyLun
> size=8.0M features='0' hwhandler='0' wp=rw
> `
On Tue, Dec 27 2016 at 10:56am -0500,
Ming Lei wrote:
> For BIO based DM, some targets aren't ready for dealing with
> bigger incoming bio than 1Mbyte, such as crypt target.
>
> Signed-off-by: Ming Lei
> ---
> drivers/md/dm.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
Hi Binoy,
On Tue, Dec 13, 2016 at 02:19:09PM +0530, Binoy Jayan wrote:
> Currently, the iv generation algorithms are implemented in dm-crypt.c.
> The goal is to move these algorithms from the dm layer to the kernel
> crypto layer by implementing them as template ciphers so they can be
> implemente
15 matches
Mail list logo
