From: tang.junhui
Hello Christophe, Ben, Hannes, Martin, Bart, and other guys:
This series of patches are modified base on:
[PATCH 00/12] multipath-tools: improve processing efficiency for addition
and deletion of multipath devices
Modifications include follows:
Martin suggested me to use nam
From: tang.junhui
Add three list iteration macros, list_for_each_entry_reverse_safe
is used for safe list iteration, and the other two macros are used
to iterate list forwards or backwards from the given begin node to
the given end node, which would be used in merging uevents.
Change-Id: I8bb53f
From: tang.junhui
merge_id is used for uevents merging, it is expected to be same with wwid,
uevents with the same merge_id will be merged, and if it is same with
wwid, only the last uevent will call domap(). now we only merge uevents
with label ID_SERIAL or ID_UID in uevent, which usually commin
From: tang.junhui
Usually calling domap() in ev_add_path() is needed, but only last path
need to call domap() in processing for merged uevents to reduce the
count of calling domap() and promote efficiency. So add input parameter
need_do_map to indicate whether need calling domap() in ev_add_path(
From: tang.junhui
This patch is mainly done to adjust the code for the preparation of
uevents merging.
Change-Id: Iaac159ffe3930e53c3325d1069c3ed497e440c0c
Signed-off-by: tang.wenjun
---
libmultipath/uevent.c | 40
multipathd/main.c | 25 ---
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 one seconds for more uevents except that
too much uevents (2048) have already been received or too much
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 merge_id is same.
Change-Id: I05ee057391c092aa0c5f989b7a4f9cb550bb4d98
Signed-off-by: tang.junhui
---
libmultipath/uevent.c
From: tang.junhui
Before merging uevents, these uevents are going to be filtered:
1) Change or addition uevent of a removed path (it indicate by an
deletion uevent occurred later), and
2) Change uevent if addition uevent of a path has not ever been
proccessed.
Change-Id: If00c2c2e23ea466c1d4643c
From: tang.junhui
Move calling filter_devnode() from uev_trigger() to uevent_can_discard()
since they do the similar work.
Change-Id: I0322443fa551b21aa3211bf1ce3fad7d37aeeab4
Signed-off-by: tang.junhui
---
libmultipath/uevent.c | 20
multipathd/main.c | 9 -
From: tang.junhui
Add merged nodes list to store nodes of merged uevents. By Adding
this member, after merging, the list of uevents would be linked like
this:
uevent
---
|struct list_head node |->list node of un-merged uevents
---
|struct
From: tang.junhui
Usually calling domap() in ev_remove_path() is needed, but only last
path need to call domap() in processing for merged uevents to reduce the
count of calling domap() and promote efficiency. So add input parameter
need_do_map to indicate whether need calling domap() in ev_remove
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” itself
would be processed with need_do_map in value of 1, which would reload
kernel t
On Tue, Jan 10 2017, Christoph Hellwig wrote:
> And require all drivers that want to support BLOCK_PC to allocate it
> as the first thing of their private data. To support this the legacy
> IDE and BSG code is switched to set cmd_size on their queues to let
> the block layer allocate the additiona
On Tue, Jan 10 2017 at 10:06am -0500,
Christoph Hellwig wrote:
> DM tries to copy a few fields around for BLOCK_PC requests, but given
> that no dm-target ever wires up scsi_cmd_ioctl BLOCK_PC can't actually
> be sent to dm.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/md/dm-rq.c | 16
On Tue, Jan 10 2017 at 10:06am -0500,
Christoph Hellwig wrote:
> Hi all,
>
> this series splits the support for SCSI passthrough commands from the
> main struct request used all over the block layer into a separate
> scsi_request structure that drivers that want to support SCSI passthough
> need
On Wed, Jan 11 2017 at 4:44am -0500,
Hannes Reinecke wrote:
> Hi all,
>
> I'd like to attend LSF/MM this year, and would like to discuss a
> redesign of the multipath handling.
>
> With recent kernels we've got quite some functionality required for
> multipathing already implemented, making so
On Wed, Jan 11 2017 at 4:37am -0500,
Hannes Reinecke wrote:
> On 01/11/2017 10:01 AM, Christoph Hellwig wrote:
> > On Wed, Jan 11, 2017 at 09:59:17AM +0100, Hannes Reinecke wrote:
> >> I'd advocate to discuss this at LSF.
> >> Now that Mike moved the bio-based mpath stuff back in things got even
On Wed, Jan 11 2017 at 3:45am -0500,
Christoph Hellwig wrote:
> On Wed, Jan 11, 2017 at 09:42:44AM +0100, Johannes Thumshirn wrote:
> > On Tue, Jan 10, 2017 at 04:06:19PM +0100, Christoph Hellwig wrote:
> > > Simply the boilerplate code needed for bsg nodes a bit.
> > >
> > > Signed-off-by: Chr
Hi Binoy,
2016-12-13 9:49 GMT+01:00 Binoy Jayan :
> 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
> implemented in hardware for per
Hi all,
I'd like to attend LSF/MM this year, and would like to discuss a
redesign of the multipath handling.
With recent kernels we've got quite some functionality required for
multipathing already implemented, making some design decisions of the
original multipath-tools implementation quite poin
On 01/11/2017 10:01 AM, Christoph Hellwig wrote:
> On Wed, Jan 11, 2017 at 09:59:17AM +0100, Hannes Reinecke wrote:
>> I'd advocate to discuss this at LSF.
>> Now that Mike moved the bio-based mpath stuff back in things got even
>> more complex.
>
> Yeah. If we'd _only_ have bio based support it
On Wed, Jan 11, 2017 at 09:56:01AM +0100, Johannes Thumshirn wrote:
> I'll dig it up and RFC post it. It's currently untested though as I
> currently don't have a SMP capable SAS HBA here.
>
> Do you have an mptXsas available?
Unfortunately not. But I think Hannes has, he has recently played
ar
On Wed, Jan 11, 2017 at 09:59:17AM +0100, Hannes Reinecke wrote:
> I'd advocate to discuss this at LSF.
> Now that Mike moved the bio-based mpath stuff back in things got even
> more complex.
Yeah. If we'd _only_ have bio based support it would simplify things
a lot, but as a third parallel path
On 01/11/2017 09:45 AM, Christoph Hellwig wrote:
> On Wed, Jan 11, 2017 at 09:42:44AM +0100, Johannes Thumshirn wrote:
>> On Tue, Jan 10, 2017 at 04:06:19PM +0100, Christoph Hellwig wrote:
>>> Simply the boilerplate code needed for bsg nodes a bit.
>>>
>>> Signed-off-by: Christoph Hellwig
>>> ---
On Wed, Jan 11, 2017 at 09:45:12AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 11, 2017 at 09:42:44AM +0100, Johannes Thumshirn wrote:
> > On Tue, Jan 10, 2017 at 04:06:19PM +0100, Christoph Hellwig wrote:
> > > Simply the boilerplate code needed for bsg nodes a bit.
> > >
> > > Signed-off-by: C
Hi,
During a multipath failover we are getting a crash like this below. The
host is booting from an FCoE device so as the root disk is a remote LUN
somewhere in the network. The failing over is intended behavior - we
disconnect all the network links for a short period of time while still
queuing a
On Wed, Jan 11, 2017 at 09:42:44AM +0100, Johannes Thumshirn wrote:
> On Tue, Jan 10, 2017 at 04:06:19PM +0100, Christoph Hellwig wrote:
> > Simply the boilerplate code needed for bsg nodes a bit.
> >
> > Signed-off-by: Christoph Hellwig
> > ---
>
> that reminds me of posting my SAS bsg-lib patc
On Tue, Jan 10, 2017 at 04:06:19PM +0100, Christoph Hellwig wrote:
> Simply the boilerplate code needed for bsg nodes a bit.
>
> Signed-off-by: Christoph Hellwig
> ---
that reminds me of posting my SAS bsg-lib patch...
Anyways looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn
On Wed, Jan 11, 2017 at 09:26:46AM +0100, Johannes Thumshirn wrote:
> Isn't that one already queued in Jens' tree?
Yes, it's now queued up. Patch 2 was submitted as well and should
hopefully go into the next 4.10 RC.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/lis
On Tue, Jan 10, 2017 at 04:06:06PM +0100, Christoph Hellwig wrote:
> Most users of BLOCK_PC requests allocate the sense buffer on the stack,
> so to avoid DMA to the stack copy them to a field in the heap allocated
> virtblk_req structure. Without that any attempt at SCSI passthrough I/O,
> includ
30 matches
Mail list logo
