Re: [dm-devel] [PATCH] multipath-tools: improve processing efficiency for addition and deletion of multipath devices

On Fri, Feb 17, 2017 at 10:48:44AM +0100, Martin Wilck wrote: > On Fri, 2017-02-17 at 00:21 -0600, Benjamin Marzinski wrote: > > On Thu, Feb 16, 2017 at 11:38:36PM -0600, Benjamin Marzinski wrote: > > > > > + > > > > > +bool > > > > > +merge_need_stop(struct uevent *earlier, struct uevent *later)

Re: [dm-devel] [PATCH v2] dm: switch dm-verity to async hash crypto API

Hi Milan, Thank you for the review and testing. On Fri, Feb 17, 2017 at 3:00 PM, Milan Broz wrote: > On 02/06/2017 02:58 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

Re: [dm-devel] hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Fri, Feb 17 2017 at 4:04am -0500, h...@infradead.org wrote: > On Thu, Feb 16, 2017 at 01:21:29PM -0500, Mike Snitzer wrote: > > multipath-tools has tables that specify all the defaults for a given > > target backend. NVMe will just be yet another. > > No, if we get

Re: [dm-devel] [PATCH v2] dm: switch dm-verity to async hash crypto API

Hi Milan, Thank you for the review and testing. On Fri, Feb 17, 2017 at 3:00 PM, Milan Broz wrote: > On 02/06/2017 02:58 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

Re: [dm-devel] hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Fri, Feb 17 2017 at 4:05am -0500, Christoph Hellwig wrote: > On Thu, Feb 16, 2017 at 08:05:36PM +0200, Sagi Grimberg wrote: > > I guess one config option that we'd need is multibus vs. failover > > which are used per use-case. > > Which fundamentally is a property of the

Re: [dm-devel] hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Fri, Feb 17 2017 at 4:33am -0500, Christoph Hellwig wrote: > On Thu, Feb 16, 2017 at 10:13:37AM -0500, Mike Snitzer wrote: > > Not following what you're saying Keith did. Please feel free to > > clarify. > > Keith demonstrated what it takes to support NVMe with dm. He

Re: [dm-devel] 答复: Re: [PATCH] multipath-tools: improve processing efficiency for addition and deletion of multipath devices

On Fri, 2017-02-17 at 11:24 +0800, tang.jun...@zte.com.cn wrote: > Hello Martin, > > Thanks for your responsible, > > ＞ I'd like the following better for this check. It uses much less cyc > les. > > ＞  static bool > ＞ can_discard_by_devpath(const char *devpath) > > ＞ This would be better 

Re: [dm-devel] [PATCH] multipath-tools: improve processing efficiency for addition and deletion of multipath devices

On Fri, 2017-02-17 at 15:41 +0800, tang.jun...@zte.com.cn wrote: > > Hello Ben, > > It's too later now,  I think you'd better go bed, haha. > > ＞ ＞ ＞ The first case should have been reduced to "remove path1 | > remove path2 > ＞ ＞ ＞ | add path3" by filtering beforehand. I suppose you want to >

Re: [dm-devel] hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Thu, Feb 16, 2017 at 10:13:37AM -0500, Mike Snitzer wrote: > Not following what you're saying Keith did. Please feel free to > clarify. Keith demonstrated what it takes to support NVMe with dm. He also gave a couple presentations on it in addition to various ptches on the list. > The middle

Re: [dm-devel] hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Thu, Feb 16, 2017 at 01:21:29PM -0500, Mike Snitzer wrote: > multipath-tools has tables that specify all the defaults for a given > target backend. NVMe will just be yet another. No, if we get things right it won't. ALUA already got rid of most of the parameter people would have to set under

Re: [dm-devel] hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Thu, Feb 16, 2017 at 08:05:36PM +0200, Sagi Grimberg wrote: > I guess one config option that we'd need is multibus vs. failover > which are used per use-case. Which fundamentally is a property of the target first, and it should tell us that. There might be the occasional need for an override,

[dm-devel] you cannot run this tool with these options on live metadata

Hi, After creating a LVM cache LV, I have the following devices in /dev/mapper: MyCache-CacheDataLV_cdata MyCache-CacheDataLV_cmeta MyCache-OriginLV MyCache-OriginLV_corig I want to use cache_check to check the cache metadata: # cache_check /dev/mapper/MyCache-CacheDataLV_cmeta syscall 'open'