On 03/14/2014 02:13 PM, Mike Snitzer wrote:
> Yeah, not sure why single path scsi_debug "just works", maybe it is a
> "feature" of the older multipathd I have kicking around?, but for basic
> data path testing scsi_debug is a quick means to an end. I can look
> closer at _why_ it gets multipathd
On 03/14/2014 02:13 PM, Mike Snitzer wrote:
Yeah, not sure why single path scsi_debug just works, maybe it is a
feature of the older multipathd I have kicking around?, but for basic
data path testing scsi_debug is a quick means to an end. I can look
closer at _why_ it gets multipathd in a
On Fri, Mar 14, 2014 at 10:13:01AM -0400, Mike Snitzer wrote:
> I was more reacting to the assertion you made like multipath regresses
> all the time. I'm not faulting you at all for not having tested
> multipath. Hell, I even forget to test multipath more than I should.
> /me says with shame
On Fri, Mar 14, 2014 at 10:13:01AM -0400, Mike Snitzer wrote:
I was more reacting to the assertion you made like multipath regresses
all the time. I'm not faulting you at all for not having tested
multipath. Hell, I even forget to test multipath more than I should.
/me says with shame
And I
On Fri, Mar 14 2014 at 9:23am -0400,
Christoph Hellwig wrote:
> On Fri, Mar 14, 2014 at 09:00:21AM -0400, Mike Snitzer wrote:
> > > Getting a little upset, eh? I didn't say it's broken, I said it gets
> > > very little testing. The regression from me was found like so many
> > > before only
On Fri, Mar 14, 2014 at 09:00:21AM -0400, Mike Snitzer wrote:
> > Getting a little upset, eh? I didn't say it's broken, I said it gets
> > very little testing. The regression from me was found like so many
> > before only after it was backported o some enterprise kernel.
>
> Even _really_ basic
On Fri, Mar 14 2014 at 5:25am -0400,
Christoph Hellwig wrote:
> On Thu, Mar 13, 2014 at 12:13:47PM -0400, Mike Snitzer wrote:
> > Pretty ironic that in the same email that you ask someone to "Let's make
> > this a little less personal." you start by asserting upstream
> > dm-multipath sees very
On Fri, Mar 14, 2014 at 10:30:53AM +0100, Hannes Reinecke wrote:
> That was actually one of my plans, move dm-multipath over to use
> blk-mq. But then I'd need to discuss with Jens et al how to best
> achieve this; the current static hctx allocation doesn't play well
> with multipaths dynamic path
On 03/14/2014 11:58 AM, Christoph Hellwig wrote:
> On Fri, Mar 14, 2014 at 10:52:55AM +0100, Hannes Reinecke wrote:
>> No, I haven't. This issue is only exhibited if you try to run
>> multipath on a non-SCSI device (in this case it was cciss).
>> But then that project got abandoned, and there
On Fri, Mar 14, 2014 at 10:52:55AM +0100, Hannes Reinecke wrote:
> No, I haven't. This issue is only exhibited if you try to run
> multipath on a non-SCSI device (in this case it was cciss).
> But then that project got abandoned, and there never was a machine
> with a multipathed cciss controller.
On 03/14/2014 10:34 AM, Christoph Hellwig wrote:
> On Fri, Mar 14, 2014 at 02:25:19AM -0700, Christoph Hellwig wrote:
>> b) is a bit harder, but we should think hard about it when rewriting the
>> multipath code to support blk-mq. Talking about which I think trying to
>> use dm-multipath on any
On Fri, Mar 14, 2014 at 02:25:19AM -0700, Christoph Hellwig wrote:
> b) is a bit harder, but we should think hard about it when rewriting the
> multipath code to support blk-mq. Talking about which I think trying to
> use dm-multipath on any blk-mq device will go horribly crash and boom at
> the
On 03/14/2014 10:25 AM, Christoph Hellwig wrote:
> On Thu, Mar 13, 2014 at 12:13:47PM -0400, Mike Snitzer wrote:
>> Pretty ironic that in the same email that you ask someone to "Let's make
>> this a little less personal." you start by asserting upstream
>> dm-multipath sees very little testing --
On Thu, Mar 13, 2014 at 12:13:47PM -0400, Mike Snitzer wrote:
> Pretty ironic that in the same email that you ask someone to "Let's make
> this a little less personal." you start by asserting upstream
> dm-multipath sees very little testing -- and use your commit that
> recently broke dm-multipath
On Thu, Mar 13, 2014 at 12:13:47PM -0400, Mike Snitzer wrote:
Pretty ironic that in the same email that you ask someone to Let's make
this a little less personal. you start by asserting upstream
dm-multipath sees very little testing -- and use your commit that
recently broke dm-multipath as
On 03/14/2014 10:25 AM, Christoph Hellwig wrote:
On Thu, Mar 13, 2014 at 12:13:47PM -0400, Mike Snitzer wrote:
Pretty ironic that in the same email that you ask someone to Let's make
this a little less personal. you start by asserting upstream
dm-multipath sees very little testing -- and use
On Fri, Mar 14, 2014 at 02:25:19AM -0700, Christoph Hellwig wrote:
b) is a bit harder, but we should think hard about it when rewriting the
multipath code to support blk-mq. Talking about which I think trying to
use dm-multipath on any blk-mq device will go horribly crash and boom at
the
On 03/14/2014 10:34 AM, Christoph Hellwig wrote:
On Fri, Mar 14, 2014 at 02:25:19AM -0700, Christoph Hellwig wrote:
b) is a bit harder, but we should think hard about it when rewriting the
multipath code to support blk-mq. Talking about which I think trying to
use dm-multipath on any blk-mq
On Fri, Mar 14, 2014 at 10:52:55AM +0100, Hannes Reinecke wrote:
No, I haven't. This issue is only exhibited if you try to run
multipath on a non-SCSI device (in this case it was cciss).
But then that project got abandoned, and there never was a machine
with a multipathed cciss controller.
We
On 03/14/2014 11:58 AM, Christoph Hellwig wrote:
On Fri, Mar 14, 2014 at 10:52:55AM +0100, Hannes Reinecke wrote:
No, I haven't. This issue is only exhibited if you try to run
multipath on a non-SCSI device (in this case it was cciss).
But then that project got abandoned, and there never was a
On Fri, Mar 14, 2014 at 10:30:53AM +0100, Hannes Reinecke wrote:
That was actually one of my plans, move dm-multipath over to use
blk-mq. But then I'd need to discuss with Jens et al how to best
achieve this; the current static hctx allocation doesn't play well
with multipaths dynamic path
On Fri, Mar 14 2014 at 5:25am -0400,
Christoph Hellwig h...@infradead.org wrote:
On Thu, Mar 13, 2014 at 12:13:47PM -0400, Mike Snitzer wrote:
Pretty ironic that in the same email that you ask someone to Let's make
this a little less personal. you start by asserting upstream
dm-multipath
On Fri, Mar 14, 2014 at 09:00:21AM -0400, Mike Snitzer wrote:
Getting a little upset, eh? I didn't say it's broken, I said it gets
very little testing. The regression from me was found like so many
before only after it was backported o some enterprise kernel.
Even _really_ basic
On Fri, Mar 14 2014 at 9:23am -0400,
Christoph Hellwig h...@infradead.org wrote:
On Fri, Mar 14, 2014 at 09:00:21AM -0400, Mike Snitzer wrote:
Getting a little upset, eh? I didn't say it's broken, I said it gets
very little testing. The regression from me was found like so many
On Wed, Mar 12 2014 at 6:28am -0400,
Christoph Hellwig wrote:
> On Sat, Mar 08, 2014 at 08:51:18PM +0100, Hannes Reinecke wrote:
> > Hey, calm down.
> > I've made the fix just two days ago. And was quite surprised that
> > I've been the first hitting that; should've crashed for everybody
> >
On Wed, Mar 12 2014 at 6:28am -0400,
Christoph Hellwig h...@infradead.org wrote:
On Sat, Mar 08, 2014 at 08:51:18PM +0100, Hannes Reinecke wrote:
Hey, calm down.
I've made the fix just two days ago. And was quite surprised that
I've been the first hitting that; should've crashed for
On 03/12/2014 11:55 AM, Christoph Hellwig wrote:
> On Wed, Mar 12, 2014 at 11:50:13AM +0100, Hannes Reinecke wrote:
>> >From the device-mapper side we have these patches which are not
>> included upstream:
>
> Another one on the dm side that seems useful is:
>
> dm-emulate-blkrrpart-ioctl:
>
On Wed, Mar 12, 2014 at 11:50:13AM +0100, Hannes Reinecke wrote:
> >From the device-mapper side we have these patches which are not
> included upstream:
Another one on the dm side that seems useful is:
dm-emulate-blkrrpart-ioctl:
Partitions on device-mapper devices are managed by kpartx (if at
On 03/12/2014 11:28 AM, Christoph Hellwig wrote:
> On Sat, Mar 08, 2014 at 08:51:18PM +0100, Hannes Reinecke wrote:
>> Hey, calm down.
>> I've made the fix just two days ago. And was quite surprised that
>> I've been the first hitting that; should've crashed for everybody
>> using dm-multipath.
>>
On Sat, Mar 08, 2014 at 08:51:18PM +0100, Hannes Reinecke wrote:
> Hey, calm down.
> I've made the fix just two days ago. And was quite surprised that
> I've been the first hitting that; should've crashed for everybody
> using dm-multipath.
> And given the pushback I've gotten recently from
On Sat, Mar 08, 2014 at 08:51:18PM +0100, Hannes Reinecke wrote:
Hey, calm down.
I've made the fix just two days ago. And was quite surprised that
I've been the first hitting that; should've crashed for everybody
using dm-multipath.
And given the pushback I've gotten recently from patches I
On 03/12/2014 11:28 AM, Christoph Hellwig wrote:
On Sat, Mar 08, 2014 at 08:51:18PM +0100, Hannes Reinecke wrote:
Hey, calm down.
I've made the fix just two days ago. And was quite surprised that
I've been the first hitting that; should've crashed for everybody
using dm-multipath.
And given
On Wed, Mar 12, 2014 at 11:50:13AM +0100, Hannes Reinecke wrote:
From the device-mapper side we have these patches which are not
included upstream:
Another one on the dm side that seems useful is:
dm-emulate-blkrrpart-ioctl:
Partitions on device-mapper devices are managed by kpartx (if at
On 03/12/2014 11:55 AM, Christoph Hellwig wrote:
On Wed, Mar 12, 2014 at 11:50:13AM +0100, Hannes Reinecke wrote:
From the device-mapper side we have these patches which are not
included upstream:
Another one on the dm side that seems useful is:
dm-emulate-blkrrpart-ioctl:
Partitions
On 03/08/2014 07:13 PM, Mike Snitzer wrote:
On Sat, Mar 8, 2014 at 2:51 PM, Hannes Reinecke wrote:
On 03/08/2014 06:33 PM, Mike Snitzer wrote:
On Sat, Mar 8, 2014 at 10:52 AM, Christoph Hellwig
wrote:
On Fri, Mar 07, 2014 at 03:45:09PM -0500, Jeff Moyer wrote:
Hi, Christoph,
Did you
On Sat, Mar 8, 2014 at 2:51 PM, Hannes Reinecke wrote:
> On 03/08/2014 06:33 PM, Mike Snitzer wrote:
>>
>> On Sat, Mar 8, 2014 at 10:52 AM, Christoph Hellwig
>> wrote:
>>>
>>> On Fri, Mar 07, 2014 at 03:45:09PM -0500, Jeff Moyer wrote:
Hi, Christoph,
Did you mean to switch
On 03/08/2014 06:33 PM, Mike Snitzer wrote:
On Sat, Mar 8, 2014 at 10:52 AM, Christoph Hellwig wrote:
On Fri, Mar 07, 2014 at 03:45:09PM -0500, Jeff Moyer wrote:
Hi, Christoph,
Did you mean to switch from list_add to list_add_tail? That seems like
a change that warrants mention.
No, that
On Sat, Mar 8, 2014 at 10:52 AM, Christoph Hellwig wrote:
> On Fri, Mar 07, 2014 at 03:45:09PM -0500, Jeff Moyer wrote:
>> Hi, Christoph,
>>
>> Did you mean to switch from list_add to list_add_tail? That seems like
>> a change that warrants mention.
>
> No, that wasn't intentional and should be
On Fri, Mar 07, 2014 at 03:45:09PM -0500, Jeff Moyer wrote:
> Hi, Christoph,
>
> Did you mean to switch from list_add to list_add_tail? That seems like
> a change that warrants mention.
No, that wasn't intentional and should be fixed. Btw, there was another
issue with that commit, in that
On Fri, Mar 07, 2014 at 03:45:09PM -0500, Jeff Moyer wrote:
Hi, Christoph,
Did you mean to switch from list_add to list_add_tail? That seems like
a change that warrants mention.
No, that wasn't intentional and should be fixed. Btw, there was another
issue with that commit, in that
On Sat, Mar 8, 2014 at 10:52 AM, Christoph Hellwig h...@infradead.org wrote:
On Fri, Mar 07, 2014 at 03:45:09PM -0500, Jeff Moyer wrote:
Hi, Christoph,
Did you mean to switch from list_add to list_add_tail? That seems like
a change that warrants mention.
No, that wasn't intentional and
On 03/08/2014 06:33 PM, Mike Snitzer wrote:
On Sat, Mar 8, 2014 at 10:52 AM, Christoph Hellwig h...@infradead.org wrote:
On Fri, Mar 07, 2014 at 03:45:09PM -0500, Jeff Moyer wrote:
Hi, Christoph,
Did you mean to switch from list_add to list_add_tail? That seems like
a change that warrants
On Sat, Mar 8, 2014 at 2:51 PM, Hannes Reinecke h...@suse.de wrote:
On 03/08/2014 06:33 PM, Mike Snitzer wrote:
On Sat, Mar 8, 2014 at 10:52 AM, Christoph Hellwig h...@infradead.org
wrote:
On Fri, Mar 07, 2014 at 03:45:09PM -0500, Jeff Moyer wrote:
Hi, Christoph,
Did you mean to switch
On 03/08/2014 07:13 PM, Mike Snitzer wrote:
On Sat, Mar 8, 2014 at 2:51 PM, Hannes Reinecke h...@suse.de wrote:
On 03/08/2014 06:33 PM, Mike Snitzer wrote:
On Sat, Mar 8, 2014 at 10:52 AM, Christoph Hellwig h...@infradead.org
wrote:
On Fri, Mar 07, 2014 at 03:45:09PM -0500, Jeff Moyer
Christoph Hellwig writes:
> Witch to using a preallocated flush_rq for blk-mq similar to what's done
> with the old request path. This allows us to set up the request properly
> with a tag from the actually allowed range and ->rq_disk as needed by
> some drivers. To make life easier we also
Christoph Hellwig h...@infradead.org writes:
Witch to using a preallocated flush_rq for blk-mq similar to what's done
with the old request path. This allows us to set up the request properly
with a tag from the actually allowed range and -rq_disk as needed by
some drivers. To make life
On Sat, Feb 08, 2014 at 08:55:07AM +0800, Shaohua Li wrote:
> Yep, none driver needs it. But reverse mapping is the one of the points we use
> tag, so better we prepare it.
I don't think adding unused code to tree for a future driver is a good
idea, although I'm happy to help out with the
On Sat, Feb 08, 2014 at 08:55:07AM +0800, Shaohua Li wrote:
Yep, none driver needs it. But reverse mapping is the one of the points we use
tag, so better we prepare it.
I don't think adding unused code to tree for a future driver is a good
idea, although I'm happy to help out with the
On Fri, Feb 07, 2014 at 06:19:15AM -0800, Christoph Hellwig wrote:
> On Fri, Feb 07, 2014 at 09:18:27AM +0800, Shaohua Li wrote:
> > Reusing the tag for flush request is considered before. The problem is
> > driver
> > need get a request from a tag, reusing tag breaks this. The possible
> >
On Fri, Feb 07, 2014 at 09:18:27AM +0800, Shaohua Li wrote:
> Reusing the tag for flush request is considered before. The problem is driver
> need get a request from a tag, reusing tag breaks this. The possible solution
> is we provide a blk_mq_tag_to_request, and force driver uses it. And in this
On Fri, Feb 07, 2014 at 09:18:27AM +0800, Shaohua Li wrote:
Reusing the tag for flush request is considered before. The problem is driver
need get a request from a tag, reusing tag breaks this. The possible solution
is we provide a blk_mq_tag_to_request, and force driver uses it. And in this
On Fri, Feb 07, 2014 at 06:19:15AM -0800, Christoph Hellwig wrote:
On Fri, Feb 07, 2014 at 09:18:27AM +0800, Shaohua Li wrote:
Reusing the tag for flush request is considered before. The problem is
driver
need get a request from a tag, reusing tag breaks this. The possible
solution
is
On Thu, Jan 30, 2014 at 05:26:30AM -0800, Christoph Hellwig wrote:
> Witch to using a preallocated flush_rq for blk-mq similar to what's done
> with the old request path. This allows us to set up the request properly
> with a tag from the actually allowed range and ->rq_disk as needed by
> some
On Thu, Jan 30, 2014 at 05:26:30AM -0800, Christoph Hellwig wrote:
Witch to using a preallocated flush_rq for blk-mq similar to what's done
with the old request path. This allows us to set up the request properly
with a tag from the actually allowed range and -rq_disk as needed by
some
Witch to using a preallocated flush_rq for blk-mq similar to what's done
with the old request path. This allows us to set up the request properly
with a tag from the actually allowed range and ->rq_disk as needed by
some drivers. To make life easier we also switch to dynamic allocation
of
Witch to using a preallocated flush_rq for blk-mq similar to what's done
with the old request path. This allows us to set up the request properly
with a tag from the actually allowed range and -rq_disk as needed by
some drivers. To make life easier we also switch to dynamic allocation
of
56 matches
Mail list logo
