Re: [dm-devel] [BUG][next-20170523][Bisected cf22cd5f3a] kernel oops while running trinity fuzzer

2017-05-24 Thread Milan Broz 
On 05/24/2017 11:29 AM, Abdul Haleem wrote:
> Hi
> 
> commit cf22cd5f3a: dm crypt: add cryptographic data integrity protection
> suspected to be bad.

Isn't this false positive? That commit changes only dm-crypt and that module
seems not to be even loaded...
(Moreover config has disabled block integrity so this code should
be mostly compiled out.)

Milan

> 
> Test : trinity
> Machine : Power 8 (LPAR)
> kernel : 4.12.0-rc2-next-20170523
> Config : attached
> 
> Unable to handle kernel paging request for data at address 0x
> Faulting instruction address: 0xc15d8824
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=2048 
> NUMA 
> pSeries
> Dumping ftrace buffer: 
>(ftrace buffer empty)
> Modules linked in: bridge nfnetlink rpadlpar_io stp llc rpaphp xt_tcpudp
> ipt_REJECT nf_reject_ipv4 xt_conntrack iptable_nat nf_conntrack_ipv4
> nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle
> iptable_filter vmx_crypto pseries_rng rng_core binfmt_misc nfsd
> ip_tables x_tables autofs4 [last unloaded: bridge]
> CPU: 4 PID: 2474 Comm: trinity-c4 Not tainted 
> 4.12.0-rc2-next-20170523-autotest #1
> task: c003a6ae2500 task.stack: c002bf7ec000
> NIP: c15d8824 LR: c1ef855c CTR: 
> REGS: c002bf7efb00 TRAP: 0300   Not tainted  
> (4.12.0-rc2-next-20170523-autotest)
> MSR: 80009033 
>   CR: 44002841  XER: 2000  
> CFAR: c15d8810 DAR:  DSISR: 4200 SOFTE: 1 
> GPR00: 0001 c002bf7efd80 c33d3600  
> GPR04:    c3743600 
> GPR08: c3743600 0006d123 c3773600 1000 
> GPR12: 2200 ce9c1600  10035e80 
> GPR16: 10033950  10033a50  
> GPR20: 10985cc4 7d9d 1001bae0 000185f8 
> GPR24:   fffa ffea 
> GPR28: 0008 c003a8c48850 ffea  
> NIP [c15d8824] memset+0xc4/0xfc
> LR [c1ef855c] memzero_explicit+0x3c/0x70
> Call Trace:
> [c002bf7efd80] [0008] 0x8 (unreliable)
> [c002bf7efdb0] [c1e3fb30] SyS_add_key+0x1a0/0x410
> [c002bf7efe30] [c152b7e0] system_call+0x38/0xfc
> Instruction dump:
> 41820038 409d0018 f886 f8860008 f8860010 f8860018 38c60020 409e0010 
> f886 f8860008 38c60010 409f000c  38c60008 2c05
> 7cb01120 
> ---[ end trace c454dcc1309b8479 ]---
> 
> 

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

[dm-devel] [PATCH RESEND] md: Make flush bios explicitely sync

2017-05-24 Thread Jan Kara 
Commit b685d3d65ac7 "block: treat REQ_FUA and REQ_PREFLUSH as
synchronous" removed REQ_SYNC flag from WRITE_{FUA|PREFLUSH|...}
definitions.  generic_make_request_checks() however strips REQ_FUA and
REQ_PREFLUSH flags from a bio when the storage doesn't report volatile
write cache and thus write effectively becomes asynchronous which can
lead to performance regressions

Fix the problem by making sure all bios which are synchronous are
properly marked with REQ_SYNC.

CC: linux-r...@vger.kernel.org
CC: Shaohua Li 
CC: Mike Snitzer 
CC: dm-devel@redhat.com
Fixes: b685d3d65ac791406e0dfd8779cc9b3707fea5a3
Signed-off-by: Jan Kara 
---
 drivers/md/dm-snap-persistent.c | 3 ++-
 drivers/md/md.c | 2 +-
 drivers/md/raid5-cache.c| 4 ++--
 3 files changed, 5 insertions(+), 4 deletions(-)

Guys, I don't know enough about DM/MD to judge whether I've identified all the
places that want REQ_SYNC right. Can you please have a look?

diff --git a/drivers/md/dm-snap-persistent.c b/drivers/md/dm-snap-persistent.c
index b93476c3ba3f..b92ab4cb0710 100644
--- a/drivers/md/dm-snap-persistent.c
+++ b/drivers/md/dm-snap-persistent.c
@@ -741,7 +741,8 @@ static void persistent_commit_exception(struct 
dm_exception_store *store,
/*
 * Commit exceptions to disk.
 */
-   if (ps->valid && area_io(ps, REQ_OP_WRITE, REQ_PREFLUSH | REQ_FUA))
+   if (ps->valid && area_io(ps, REQ_OP_WRITE,
+REQ_SYNC | REQ_PREFLUSH | REQ_FUA))
ps->valid = 0;
 
/*
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 10367ffe92e3..212a6777ff31 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -765,7 +765,7 @@ void md_super_write(struct mddev *mddev, struct md_rdev 
*rdev,
test_bit(FailFast, >flags) &&
!test_bit(LastDev, >flags))
ff = MD_FAILFAST;
-   bio->bi_opf = REQ_OP_WRITE | REQ_PREFLUSH | REQ_FUA | ff;
+   bio->bi_opf = REQ_OP_WRITE | REQ_SYNC | REQ_PREFLUSH | REQ_FUA | ff;
 
atomic_inc(>pending_writes);
submit_bio(bio);
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 4c00bc248287..0a7af8b0a80a 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -1782,7 +1782,7 @@ static int r5l_log_write_empty_meta_block(struct r5l_log 
*log, sector_t pos,
mb->checksum = cpu_to_le32(crc32c_le(log->uuid_checksum,
 mb, PAGE_SIZE));
if (!sync_page_io(log->rdev, pos, PAGE_SIZE, page, REQ_OP_WRITE,
- REQ_FUA, false)) {
+ REQ_SYNC | REQ_FUA, false)) {
__free_page(page);
return -EIO;
}
@@ -2388,7 +2388,7 @@ r5c_recovery_rewrite_data_only_stripes(struct r5l_log 
*log,
mb->checksum = cpu_to_le32(crc32c_le(log->uuid_checksum,
 mb, PAGE_SIZE));
sync_page_io(log->rdev, ctx->pos, PAGE_SIZE, page,
-REQ_OP_WRITE, REQ_FUA, false);
+REQ_OP_WRITE, REQ_SYNC | REQ_FUA, false);
sh->log_start = ctx->pos;
list_add_tail(>r5c, >stripe_in_journal_list);
atomic_inc(>stripe_in_journal_count);
-- 
2.12.0

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

[dm-devel] [BUG][next-20170523][Bisected cf22cd5f3a] kernel oops while running trinity fuzzer

2017-05-24 Thread Abdul Haleem 
Hi

commit cf22cd5f3a: dm crypt: add cryptographic data integrity protection
suspected to be bad.

Test : trinity
Machine : Power 8 (LPAR)
kernel : 4.12.0-rc2-next-20170523
Config : attached

Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc15d8824
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2048 
NUMA 
pSeries
Dumping ftrace buffer: 
   (ftrace buffer empty)
Modules linked in: bridge nfnetlink rpadlpar_io stp llc rpaphp xt_tcpudp
ipt_REJECT nf_reject_ipv4 xt_conntrack iptable_nat nf_conntrack_ipv4
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle
iptable_filter vmx_crypto pseries_rng rng_core binfmt_misc nfsd
ip_tables x_tables autofs4 [last unloaded: bridge]
CPU: 4 PID: 2474 Comm: trinity-c4 Not tainted 4.12.0-rc2-next-20170523-autotest 
#1
task: c003a6ae2500 task.stack: c002bf7ec000
NIP: c15d8824 LR: c1ef855c CTR: 
REGS: c002bf7efb00 TRAP: 0300   Not tainted  
(4.12.0-rc2-next-20170523-autotest)
MSR: 80009033 
  CR: 44002841  XER: 2000  
CFAR: c15d8810 DAR:  DSISR: 4200 SOFTE: 1 
GPR00: 0001 c002bf7efd80 c33d3600  
GPR04:    c3743600 
GPR08: c3743600 0006d123 c3773600 1000 
GPR12: 2200 ce9c1600  10035e80 
GPR16: 10033950  10033a50  
GPR20: 10985cc4 7d9d 1001bae0 000185f8 
GPR24:   fffa ffea 
GPR28: 0008 c003a8c48850 ffea  
NIP [c15d8824] memset+0xc4/0xfc
LR [c1ef855c] memzero_explicit+0x3c/0x70
Call Trace:
[c002bf7efd80] [0008] 0x8 (unreliable)
[c002bf7efdb0] [c1e3fb30] SyS_add_key+0x1a0/0x410
[c002bf7efe30] [c152b7e0] system_call+0x38/0xfc
Instruction dump:
41820038 409d0018 f886 f8860008 f8860010 f8860018 38c60020 409e0010 
f886 f8860008 38c60010 409f000c  38c60008 2c05
7cb01120 
---[ end trace c454dcc1309b8479 ]---


-- 
Regard's

Abdul Haleem
IBM Linux Technology Centre


#
# Automatically generated file; DO NOT EDIT.
# Linux/powerpc 4.11.0-rc7 Kernel Configuration
#
CONFIG_PPC64=y

#
# Processor support
#
CONFIG_PPC_BOOK3S_64=y
# CONFIG_PPC_BOOK3E_64 is not set
# CONFIG_POWER7_CPU is not set
CONFIG_POWER8_CPU=y
CONFIG_PPC_BOOK3S=y
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_VSX=y
# CONFIG_PPC_ICSWX is not set
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_64=y
CONFIG_PPC_RADIX_MMU=y
CONFIG_PPC_MM_SLICES=y
CONFIG_PPC_HAVE_PMU_SUPPORT=y
CONFIG_PPC_PERF_CTRS=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2048
CONFIG_PPC_DOORBELL=y
# CONFIG_CPU_BIG_ENDIAN is not set
CONFIG_CPU_LITTLE_ENDIAN=y
CONFIG_PPC64_BOOT_WRAPPER=y
CONFIG_64BIT=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_MMU=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NR_IRQS=512
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_ARCH_HAS_ILOG2_U64=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK=y
CONFIG_PPC=y
# CONFIG_GENERIC_CSUM is not set
CONFIG_EARLY_PRINTK=y
CONFIG_PANIC_TIMEOUT=180
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
CONFIG_EPAPR_BOOT=y
# CONFIG_DEFAULT_UIMAGE is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
# CONFIG_PPC_OF_PLATFORM_PCI is not set
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_PPC_EMULATE_SSTEP=y
CONFIG_ZONE_DMA32=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_XZ is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y

Re: [dm-devel] [PATCH 02/15] scsi/osd: don't save block errors into req_results

2017-05-24 Thread Bart Van Assche 
On Thu, 2017-05-18 at 15:17 +0200, Christoph Hellwig wrote:
> We will only have sense data if the command exectured and got a SCSI
> result, so this is pointless.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/scsi/osd/osd_initiator.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/osd/osd_initiator.c 
> b/drivers/scsi/osd/osd_initiator.c
> index 8a1b94816419..14785177ce7b 100644
> --- a/drivers/scsi/osd/osd_initiator.c
> +++ b/drivers/scsi/osd/osd_initiator.c
> @@ -477,7 +477,7 @@ static void _set_error_resid(struct osd_request *or, 
> struct request *req,
>int error)
>  {
>   or->async_error = error;
> - or->req_errors = scsi_req(req)->result ? : error;
> + or->req_errors = scsi_req(req)->result;
>   or->sense_len = scsi_req(req)->sense_len;
>   if (or->sense_len)
>   memcpy(or->sense, scsi_req(req)->sense, or->sense_len);

Hello Christoph,

Are you sure that that code is not necessary? From osd_initiator.c:

static void _put_request(struct request *rq)
{
/*
 * If osd_finalize_request() was called but the request was not
 * executed through the block layer, then we must release BIOs.
 * TODO: Keep error code in or->async_error. Need to audit all
 *   code paths.
 */
if (unlikely(rq->bio))
blk_end_request(rq, -ENOMEM, blk_rq_bytes(rq));
else
blk_put_request(rq);
}

Bart.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [PATCH 06/15] fs: simplify dio_bio_complete

2017-05-24 Thread Bart Van Assche 
On Thu, 2017-05-18 at 15:18 +0200, Christoph Hellwig wrote:
> Only read bio->bi_error once in the common path.

Reviewed-by: Bart Van Assche 

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [PATCH 05/15] fs: remove the unused error argument to dio_end_io()

2017-05-24 Thread Bart Van Assche 
On Thu, 2017-05-18 at 15:18 +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig 

Reviewed-by: Bart Van Assche 

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [PATCH 04/15] dm: fix REQ_RAHEAD handling

2017-05-24 Thread Bart Van Assche 
On Thu, 2017-05-18 at 15:18 +0200, Christoph Hellwig wrote:
> A few (but not all) dm targets use a special EWOULDBLOCK error code for
> failing REQ_RAHEAD requests that fail due to a lack of available resources.
> But no one else knows about this magic code, and lower level drivers also
> don't generate it when failing read-ahead requests for similar reasons.
> 
> So remove this special casing and ignore all additional error handling for
> REQ_RAHEAD - if this was a real underlying error we'd get a normal read
> once the real read comes in.

Reviewed-by: Bart Van Assche 

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [PATCH RESEND] md: Make flush bios explicitely sync

2017-05-24 Thread Shaohua Li 
On Wed, May 24, 2017 at 01:40:13PM +0200, Jan Kara wrote:
> Commit b685d3d65ac7 "block: treat REQ_FUA and REQ_PREFLUSH as
> synchronous" removed REQ_SYNC flag from WRITE_{FUA|PREFLUSH|...}
> definitions.  generic_make_request_checks() however strips REQ_FUA and
> REQ_PREFLUSH flags from a bio when the storage doesn't report volatile
> write cache and thus write effectively becomes asynchronous which can
> lead to performance regressions
> 
> Fix the problem by making sure all bios which are synchronous are
> properly marked with REQ_SYNC.

Hi,

DM and MD are different trees, so probably you should separate them to 2
patches. For the md part (md.c, raid5-cache.c), some placed which use REQ_FUA
are missed, like raid5.c and raid5-ppl.c

Can't remember if others asked the question in your first post, sorry, but why
we don't add REQ_SYNC in generic_make_request_checks() if we are going to
stripe REQ_FUA, REQ_PREFLUSH. That will be less error prone.

Thanks,
Shaohua

> CC: linux-r...@vger.kernel.org
> CC: Shaohua Li 
> CC: Mike Snitzer 
> CC: dm-devel@redhat.com
> Fixes: b685d3d65ac791406e0dfd8779cc9b3707fea5a3
> Signed-off-by: Jan Kara 
> ---
>  drivers/md/dm-snap-persistent.c | 3 ++-
>  drivers/md/md.c | 2 +-
>  drivers/md/raid5-cache.c| 4 ++--
>  3 files changed, 5 insertions(+), 4 deletions(-)
> 
> Guys, I don't know enough about DM/MD to judge whether I've identified all the
> places that want REQ_SYNC right. Can you please have a look?
> 
> diff --git a/drivers/md/dm-snap-persistent.c b/drivers/md/dm-snap-persistent.c
> index b93476c3ba3f..b92ab4cb0710 100644
> --- a/drivers/md/dm-snap-persistent.c
> +++ b/drivers/md/dm-snap-persistent.c
> @@ -741,7 +741,8 @@ static void persistent_commit_exception(struct 
> dm_exception_store *store,
>   /*
>* Commit exceptions to disk.
>*/
> - if (ps->valid && area_io(ps, REQ_OP_WRITE, REQ_PREFLUSH | REQ_FUA))
> + if (ps->valid && area_io(ps, REQ_OP_WRITE,
> +  REQ_SYNC | REQ_PREFLUSH | REQ_FUA))
>   ps->valid = 0;
>  
>   /*
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 10367ffe92e3..212a6777ff31 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -765,7 +765,7 @@ void md_super_write(struct mddev *mddev, struct md_rdev 
> *rdev,
>   test_bit(FailFast, >flags) &&
>   !test_bit(LastDev, >flags))
>   ff = MD_FAILFAST;
> - bio->bi_opf = REQ_OP_WRITE | REQ_PREFLUSH | REQ_FUA | ff;
> + bio->bi_opf = REQ_OP_WRITE | REQ_SYNC | REQ_PREFLUSH | REQ_FUA | ff;
>  
>   atomic_inc(>pending_writes);
>   submit_bio(bio);
> diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
> index 4c00bc248287..0a7af8b0a80a 100644
> --- a/drivers/md/raid5-cache.c
> +++ b/drivers/md/raid5-cache.c
> @@ -1782,7 +1782,7 @@ static int r5l_log_write_empty_meta_block(struct 
> r5l_log *log, sector_t pos,
>   mb->checksum = cpu_to_le32(crc32c_le(log->uuid_checksum,
>mb, PAGE_SIZE));
>   if (!sync_page_io(log->rdev, pos, PAGE_SIZE, page, REQ_OP_WRITE,
> -   REQ_FUA, false)) {
> +   REQ_SYNC | REQ_FUA, false)) {
>   __free_page(page);
>   return -EIO;
>   }
> @@ -2388,7 +2388,7 @@ r5c_recovery_rewrite_data_only_stripes(struct r5l_log 
> *log,
>   mb->checksum = cpu_to_le32(crc32c_le(log->uuid_checksum,
>mb, PAGE_SIZE));
>   sync_page_io(log->rdev, ctx->pos, PAGE_SIZE, page,
> -  REQ_OP_WRITE, REQ_FUA, false);
> +  REQ_OP_WRITE, REQ_SYNC | REQ_FUA, false);
>   sh->log_start = ctx->pos;
>   list_add_tail(>r5c, >stripe_in_journal_list);
>   atomic_inc(>stripe_in_journal_count);
> -- 
> 2.12.0
> 

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [PATCH] multipath-tools:Prioritizer based on a latency algorithm

2017-05-24 Thread Yang Feng 


On 2017/5/25 3:57, Benjamin Marzinski wrote:
> On Wed, May 24, 2017 at 10:50:18AM +0800, Yang Feng wrote:
>> Hello Christophe,
> ACK
> 
> -Ben
>  

Hello Christophe,

Any advance for this patch?
Thanks，Best！

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [PATCH] multipath-tools:Prioritizer based on a latency algorithm

2017-05-24 Thread Benjamin Marzinski 
On Wed, May 24, 2017 at 10:50:18AM +0800, Yang Feng wrote:
> Hello Christophe,

ACK

-Ben
 
> Our technology team is working on a open source contribution for multipath.
> We think that this patch is essential to isolate the high latency paths and
> avoid high fluctuation of io performance, particularly, for the Storage-Backup
> environment of HyperCluster.
> 
> Look forward your reply very much.
> Respects and regards!
> 
> 
> 1. In the Storage-Backup environment of HyperCluster, includes one storage 
> array near
> to the host and one remote storage array, and the two storage arrays have the 
> same hardware.
> The same LUN is writed or readed by the two storage arrays.However, usually, 
> the average
> latency of the paths of the remote storage array is much higher than the near 
> storage array's.
> Apparently, the prioritizer can be a good automatic solution. And the current 
> selectors don't
> solve it, IOs will send to the paths of the remote storage array, IOPS will 
> be influenced unavoidably.
> 2. In the environment of single storage array, the prioritizer can 
> automatically separate the paths
> who's latency is much higher, IOs will not send to this paths. But the 
> current selectors don't solve
> this problem, io performance will be influenced unavoidably.
> 
> 
> The up-to-date patch as follows:
> ---
> >From 58d718fdd34550bd9c4a32c6e9a87099c1e45a9f Mon Sep 17 00:00:00 2001
> From: Yang Feng 
> Date: Fri, 19 May 2017 16:09:07 +0800
> Subject: [PATCH] libmultipath/prioritizers: Prioritizer for device mapper 
> multipath, where the corresponding priority
> values of specific paths are provided by a latency algorithm. And the latency 
> algorithm is dependent on the following
> arguments(latency_interval and io_num). The principle of the algorithm is 
> illustrated as follows:
> 1. By sending a certain number "cons_num" of read IOs to the current path 
> continuously, the IOs' average latency can be calculated.
> 2. According to the average latency of each path and the weight value 
> "latency_interval", the priority "rc" of each path can be provided.
> 
>latency_interval   latency_interval   latency_interval 
>   latency_interval
>
> |--|--|--|...|--|
>|  priority rank 1 |  priority rank 2 |  priority rank 3 |...| 
>  priority rank x |
>
> |--|--|--|...|--|
> Priority Rank Partitioning
> ---
>  libmultipath/prioritizers/Makefile   |   6 +-
>  libmultipath/prioritizers/path_latency.c | 271 
> +++
>  multipath/multipath.conf.5   |  18 ++
>  libmultipath/prio.h|   1 +
>  4 files changed, 295 insertions(+), 1 deletion(-)
>  create mode 100644 libmultipath/prioritizers/path_latency.c
> 
> diff --git a/libmultipath/prioritizers/Makefile 
> b/libmultipath/prioritizers/Makefile
> index 36b42e4..d2f20f6 100644
> --- a/libmultipath/prioritizers/Makefile
> +++ b/libmultipath/prioritizers/Makefile
> @@ -18,13 +18,17 @@ LIBS = \
>   libpriorandom.so \
>   libpriordac.so \
>   libprioweightedpath.so \
> - libpriosysfs.so
> + libpriopath_latency.so \
> + libpriosysfs.so
> 
>  all: $(LIBS)
> 
>  libprioalua.so: alua.o alua_rtpg.o
>   $(CC) $(LDFLAGS) $(SHARED_FLAGS) -o $@ $^
> 
> +libpriopath_latency.so: path_latency.o  ../checkers/libsg.o
> + $(CC) $(LDFLAGS) $(SHARED_FLAGS) -o $@ $^ -lm
> +
>  libprio%.so: %.o
>   $(CC) $(LDFLAGS) $(SHARED_FLAGS) -o $@ $^
> 
> diff --git a/libmultipath/prioritizers/path_latency.c 
> b/libmultipath/prioritizers/path_latency.c
> new file mode 100644
> index 000..a666b6c
> --- /dev/null
> +++ b/libmultipath/prioritizers/path_latency.c
> @@ -0,0 +1,271 @@
> +/*
> + * (C) Copyright HUAWEI Technology Corp. 2017, 2021   All Rights Reserved.
> + *
> + * main.c
> + *
> + * Prioritizer for device mapper multipath, where the corresponding priority
> + * values of specific paths are provided by a latency algorithm. And the
> + * latency algorithm is dependent on arguments.
> + *
> + * The principle of the algorithm as follows:
> + * 1. By sending a certain number "io_num" of read IOs to the current path
> + *continuously, the IOs' average latency can be calculated.
> + * 2. According to the average latency of each path and the weight value
> + *"latency_interval", the priority "rc" of each path can be provided.
> + *
> + * Author(s): Yang Feng 
> + *Zou Ming 
> + *
> + * This file is released under the GPL.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "debug.h"
> +#include "prio.h"
> +#include "structs.h"
> +#include "../checkers/libsg.h"
> +
> +#define THRES_USEC_VALUE12000LL/*unit: us, =120s*/
> +
>

Re: [dm-devel] [PATCH 01/15] nvme-lightnvm: use blk_execute_rq in nvme_nvm_submit_user_cmd

2017-05-24 Thread Bart Van Assche 
On Thu, 2017-05-18 at 15:17 +0200, Christoph Hellwig wrote:
> Instead of reinventing it poorly.

Reviewed-by: Bart Van Assche 

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [PATCH 03/15] gfs2: remove the unused sd_log_error field

2017-05-24 Thread Bart Van Assche 
On Thu, 2017-05-18 at 15:18 +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig 

Reviewed-by: Bart Van Assche 

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel