On Mon, 2020-08-10 at 19:36 -0400, Chuck Lever wrote:
> > On Aug 10, 2020, at 11:35 AM, James Bottomley
> > wrote:
> > On Sun, 2020-08-09 at 13:16 -0400, Mimi Zohar wrote:
> > > On Sat, 2020-08-08 at 13:47 -0400, Chuck Lever wrote:
[...]
> > > > The first priority (for me, anyway) therefore is
On Wed, Aug 05, 2020 at 10:05:19PM +0200, Martin Wilck wrote:
> On Sun, 2020-07-19 at 00:26 -0500, Benjamin Marzinski wrote:
> > On Thu, Jul 09, 2020 at 12:51:40PM +0200, mwi...@suse.com wrote:
> > > From: Martin Wilck
> > >
> > > The reason for the is_daemon parameter in disassemble_map() lies
On Mon, Aug 10 2020 at 11:32pm -0400,
Chao Leng wrote:
>
>
> On 2020/8/11 1:22, Mike Snitzer wrote:
> >On Mon, Aug 10 2020 at 10:36am -0400,
> >Mike Snitzer wrote:
> >
> >>On Fri, Aug 07 2020 at 7:35pm -0400,
> >>Sagi Grimberg wrote:
> >>
> >>>
> >Hey Mike,
> >...
> I think NVMe can
In vector_alloc_slot func, if REALLOC fails, it means new slot
allocation fails. However, it just update v->allocated and then
return the old v->slot without new slot. So, the caller will take
the last old slot as the new allocated slot, and use it by calling
vector_set_slot func. Finally, the
On 2020/8/10 22:34, Martin Wilck wrote:
> Hi Liu,
>
> thanks again for your valuable contributions and meticulous code
> review. I've added your patches in my upstream-queue branch now:
>
> https://github.com/openSUSE/multipath-tools/commits/upstream-queue
>
> Not applied yet:
>
> -
On Wed, Aug 05, 2020 at 02:05:00PM +0200, Martin Wilck wrote:
> On Fri, 2020-07-17 at 16:25 -0500, Benjamin Marzinski wrote:
> > On Thu, Jul 09, 2020 at 12:36:13PM +0200, mwi...@suse.com wrote:
> > > From: Martin Wilck
> > >
> > > If pathinfo fails for one path to be adopted, we currently
> > >
On Thu, Aug 06, 2020 at 10:48:12AM +, Martin Wilck wrote:
> On Mon, 2020-07-27 at 14:24 -0500, Benjamin Marzinski wrote:
> > pathcountgr() is never used except by pathcount(), and neither is the
> > special case for PATH_WILD. Simplify this and make one function that
> > is
> > used by both
On Fri, 7 Aug 2020, Mimi Zohar wrote:
> > > Are you planning to attend Plumbers? Perhaps we could propose a BoF
> > > session on this topic.
> >
> > That sounds like a good idea.
>
> Other than it is already sold out.
Mimi advised me off-list that she is able to attend, so I've submitted a
On Mon, 2020-08-10 at 14:07 -0500, Benjamin Marzinski wrote:
> On Mon, Aug 10, 2020 at 02:20:27PM +0200, Martin Wilck wrote:
> > Hello Liu,
> >
> > On Fri, 2020-07-24 at 09:40 +0800, Zhiqiang Liu wrote:
> > > In disassemble_map func, one pp will be allocated and stored in
> > > pgp->paths.
On Mon, Aug 10, 2020 at 02:20:27PM +0200, Martin Wilck wrote:
> Hello Liu,
>
> On Fri, 2020-07-24 at 09:40 +0800, Zhiqiang Liu wrote:
> > In disassemble_map func, one pp will be allocated and stored in
> > pgp->paths. However, if store_path fails, pp will not be freed,
> > then memory leak
On Tue, Aug 04, 2020 at 09:35:08PM +0200, Martin Wilck wrote:
> On Tue, 2020-08-04 at 11:26 -0500, Benjamin Marzinski wrote:
> > On Tue, Aug 04, 2020 at 05:18:18PM +0200, Martin Wilck wrote:
> > > On Tue, 2020-08-04 at 17:04 +0200, Martin Wilck wrote:
> > > > On Thu, 2020-07-16 at 16:17 -0500,
On Mon, Aug 10 2020 at 10:36am -0400,
Mike Snitzer wrote:
> On Fri, Aug 07 2020 at 7:35pm -0400,
> Sagi Grimberg wrote:
>
> >
> > >>Hey Mike,
...
> > >I think NVMe can easily fix this by having an earlier stage of checking,
> > >e.g. nvme_local_retry_req(), that shortcircuits ever getting to
On Mon, 2020-08-10 at 12:35 -0400, Mimi Zohar wrote:
> On Mon, 2020-08-10 at 08:35 -0700, James Bottomley wrote:
[...]
> > > Up to now, verifying remote filesystem file integrity has been
> > > out of scope for IMA. With fs-verity file signatures I can at
> > > least grasp how remote file
On Sun, 2020-08-09 at 13:16 -0400, Mimi Zohar wrote:
> On Sat, 2020-08-08 at 13:47 -0400, Chuck Lever wrote:
> > > On Aug 5, 2020, at 2:15 PM, Mimi Zohar
> > > wrote:
>
>
>
> > > If block layer integrity was enough, there wouldn't have been a
> > > need for fs-verity. Even fs-verity is
On Fri, Aug 07 2020 at 7:35pm -0400,
Sagi Grimberg wrote:
>
> >>Hey Mike,
> >>
> The point is: blk_path_error() has nothing to do with NVMe errors.
> This is dm-multipath logic stuck in the middle of the NVMe error
> handling code.
> >>>
> >>>No, it is a means to have multiple
On 2020/8/10 21:48, Martin Wilck wrote:
> Hello Liu,
>
> On Fri, 2020-07-31 at 18:41 +0800, Zhiqiang Liu wrote:
>> In vector_alloc_slot func, if REALLOC fails, it means new slot
>> allocation fails. However, it just update v->allocated and then
>> return the old v->slot without new slot. So,
Hello Liu,
On Fri, 2020-07-31 at 18:41 +0800, Zhiqiang Liu wrote:
> In vector_alloc_slot func, if REALLOC fails, it means new slot
> allocation fails. However, it just update v->allocated and then
> return the old v->slot without new slot. So, the caller will take
> the last old slot as the new
Hello Lixiaokeng,
On Thu, 2020-07-30 at 21:27 +0800, lixiaokeng wrote:
> Hi.
> I'm very sorry for subject mistake in first mail.
>
> In set_ble_device func, if blist is NULL or ble is NULL,
> the vendor and product isn't free. We think it is not
> reasonable that strdup(XXX) is used as
On 2020/8/10 20:20, Martin Wilck wrote:
> Hello Liu,
>
> On Fri, 2020-07-24 at 09:40 +0800, Zhiqiang Liu wrote:
>> In disassemble_map func, one pp will be allocated and stored in
>> pgp->paths. However, if store_path fails, pp will not be freed,
>> then memory leak problem occurs.
>>
>> Here,
Hello Liu,
On Fri, 2020-07-24 at 09:40 +0800, Zhiqiang Liu wrote:
> In disassemble_map func, one pp will be allocated and stored in
> pgp->paths. However, if store_path fails, pp will not be freed,
> then memory leak problem occurs.
>
> Here, we will call free_path to free pp when store_path
On 2020/8/10 18:17, Martin Wilck wrote:
> On Mon, 2020-08-10 at 09:14 +0800, Zhiqiang Liu wrote:
>> In checker_state_name func, we donot check whether input i
>> is valid. It may cause array access violation problem.
>>
>> Signed-off-by: Zhiqiang Liu
>> ---
>> libmultipath/checkers.c | 26
On Mon, 2020-08-10 at 09:14 +0800, Zhiqiang Liu wrote:
> In checker_state_name func, we donot check whether input i
> is valid. It may cause array access violation problem.
>
> Signed-off-by: Zhiqiang Liu
> ---
> libmultipath/checkers.c | 26 +++---
> libmultipath/checkers.h
> On Aug 5, 2020, at 2:15 PM, Mimi Zohar wrote:
>
> On Wed, 2020-08-05 at 09:59 -0700, James Morris wrote:
>> On Wed, 5 Aug 2020, James Bottomley wrote:
>>
>>> I'll leave Mimi to answer, but really this is exactly the question that
>>> should have been asked before writing IPE. However,
Having said all of this, I think one thing which could be done to help support
NVMe with DMP is to approximate any new NVMe error semantics by adding new
BLK_STS codes. Reusing or overloading existing BLK_STS may not work well
because everyone else already has a claim on those semantics. I
On Sat, 2020-08-08 at 13:47 -0400, Chuck Lever wrote:
> > On Aug 5, 2020, at 2:15 PM, Mimi Zohar wrote:
> > If block layer integrity was enough, there wouldn't have been a need
> > for fs-verity. Even fs-verity is limited to read only filesystems,
> > which makes validating file integrity so
I'd like to up level this whole conversation for a minute by talking about
exactly what ACRE does.
The genesis of the changes discussed in this thread is NVMe TP-4033 - Enhanced
Command Retry. You can find a copy of this TP here:
Hi,
for many years we have been operating some Promise VTrak arrays
without any use of the ALUA feature (largely so we don't have to
specify LUN affinities as well, which seems to be required).
In the process of upgrading to Debian Buster
(multipath-tools 0.7.9 and kernel 4.19)
I find that I can
On Sat, 2020-08-08 at 02:41 +1000, James Morris wrote:
> On Thu, 6 Aug 2020, Mimi Zohar wrote:
>
> > On Thu, 2020-08-06 at 09:51 +1000, James Morris wrote:
> > > On Wed, 5 Aug 2020, Mimi Zohar wrote:
> > >
> > > > If block layer integrity was enough, there wouldn't have been a need
> > > > for
On Fri, 2020-08-07 at 13:31 -0400, Mimi Zohar wrote:
> On Sat, 2020-08-08 at 02:41 +1000, James Morris wrote:
> > On Thu, 6 Aug 2020, Mimi Zohar wrote:
> >
> > > On Thu, 2020-08-06 at 09:51 +1000, James Morris wrote:
> > > > On Wed, 5 Aug 2020, Mimi Zohar wrote:
> > > >
> > > > > If block layer
29 matches
Mail list logo
