Vivek Goyal writes:
> Currently pmem_clear_poison() expects offset and len to be sector aligned.
> Atleast that seems to be the assumption with which code has been written.
> It is called only from pmem_do_bvec() which is called only from pmem_rw_page()
> and pmem_make_request() which will only p
Vivek Goyal writes:
> On Thu, Feb 20, 2020 at 04:35:17PM -0500, Jeff Moyer wrote:
>> Vivek Goyal writes:
>>
>> > Currently pmem_clear_poison() expects offset and len to be sector aligned.
>> > Atleast that seems to be the assumption with which code has been wri
Dan Williams writes:
> Oh you misunderstood my comment, the "move badblocks to filesystem"
> proposal is long term / down the road thing to consider. In the near
> term this unaligned block zeroing facility is an improvement.
I'm not sure I agree. I'm going to think about it and get back to you
Dan Williams writes:
> On Sun, Feb 23, 2020 at 3:03 PM Dave Chinner wrote:
>>
>> On Fri, Feb 21, 2020 at 03:17:59PM -0500, Vivek Goyal wrote:
>> > On Fri, Feb 21, 2020 at 01:32:48PM -0500, Jeff Moyer wrote:
>> > > Vivek Goyal writes:
>> > >
&
Dan Williams writes:
>> Let's just focus on reporting errors when we know we have them.
>
> That's the problem in my eyes. If software needs to contend with
> latent error reporting then it should always contend otherwise
> software has multiple error models to wrangle.
The only way for an appli
Dan Williams writes:
> On Mon, Feb 24, 2020 at 1:53 PM Jeff Moyer wrote:
>>
>> Dan Williams writes:
>>
>> >> Let's just focus on reporting errors when we know we have them.
>> >
>> > That's the problem in my eyes. If software nee
Hi, Mikulas,
Mikulas Patocka writes:
> On Wed, 3 Mar 2021, JeffleXu wrote:
>
>>
>>
>> On 3/3/21 3:05 AM, Mikulas Patocka wrote:
>>
>> > Support I/O polling if submit_bio_noacct_mq_direct returned non-empty
>> > cookie.
>> >
>> > Signed-off-by: Mikulas Patocka
>> >
>> > ---
>> > drivers/md
ecause it's an internaly only detail,
that makes sense. I think testing for blocking makes more sense than
testing for the existence of srcu, so this actually makes the code a bit
more readable in my opinion.
Reviewed-by: Jeff Moyer
>
> Signed-off-by: Ming Lei
> ---
> block/bl
Ming Lei writes:
> Add blk_alloc_disk_srcu() so that we can allocate srcu inside request queue
> for supporting blocking ->queue_rq().
>
> dm-rq needs this API.
>
> Signed-off-by: Ming Lei
Reviewed-by: Jeff Moyer
> ---
> block/genhd.c | 5 +++--
&g
eforehand.
>
> Signed-off-by: Ming Lei
Acked-by: Jeff Moyer
> ---
> drivers/md/dm-rq.c| 5 -
> drivers/md/dm-rq.h| 3 ++-
> drivers/md/dm-table.c | 14 ++
> drivers/md/dm.c | 5 +++--
> drivers/md/dm.h | 1 +
> 5 files changed, 24 in
Christoph Hellwig writes:
> On Tue, Dec 28, 2021 at 04:30:08PM -0500, Mike Snitzer wrote:
>> Yeah, people use request-based for IO scheduling and more capable path
>> selectors. Imposing bio-based would be a pretty jarring workaround for
>> BLK_MQ_F_BLOCKING. request-based DM should properly sup
"Yang, Xiao/杨 晓" writes:
> Hi Ross, Toshi, Jeff and others
>
> After reading the kernel patches[1][2][3] about dm, I think only three
> types(linear, stripe and log-writes) of dm can support DAX now, right?
Right.
> I wonder why only three types of dm need to support DAX? Is there any
> reason/
"Yang, Xiao/杨 晓" writes:
> Hi Jeff,
>
> Thanks a lot for your reply.
>
> On 2022/9/27 3:52, Jeff Moyer wrote:
>> "Yang, Xiao/杨 晓" writes:
>>
>>> Hi Ross, Toshi, Jeff and others
>>>
>>> After reading the kernel patches[1][
exactly one caller of trace_block_bio_complete
and one caller of trace_block_rq_complete. More importantly, all
bio-based drivers now generate C events, which is useful for
performance analysis.
Suggested-by: Christoph Hellwig
Signed-off-by: Jeff Moyer
---
Testing: I made sure that request-based
Jens Axboe writes:
> On 01/17/2017 01:57 PM, Jeff Moyer wrote:
>> Only a few bio-based drivers actually generate blktrace completion
>> (C) events. Instead of changing all bio-based drivers to call
>> trace_block_bio_complete, move the tracing to bio_complete, and remove
&g
Hi, Jens,
Jens Axboe writes:
> I like the change, hate the naming. I'd prefer one of two things:
>
> - Add bio_endio_complete() instead. That name sucks too, the
> important part is flipping the __name() to have a trace
> version instead.
ITYM a notrace version. By default, we want tracing
Hou Tao writes:
> Hi all,
>
> We need to throttle the O_DIRECT IO on data and metadata device
> of a dm-thin pool and encounter some problems. If we set the
> limitation on the root blkcg, the throttle works. If we set the
> limitation on a child blkcg, the throttle doesn't work well.
>
> The rea
Shaun Tancheff writes:
> In a few places a temporary value smaller than a cmd_flags
> is used to test for bits and or build up a new cmd_flags.
>
> Change to use explicit u64 values where appropriate.
This is not a bug fix, so please fix your subject.
I'm not against cleaning up the mixing of 3
mchri...@redhat.com writes:
> The following patches begin to cleanup the request->cmd_flags and
> bio->bi_rw mess. We currently use cmd_flags to specify the operation,
> attributes and state of the request. For bi_rw we use it for similar
> info and also the priority but then also have another bi_
Mike Christie writes:
> On 05/03/2016 03:44 PM, Jeff Moyer wrote:
>> Hi, Mike,
>>
>> That git tree doesn't seem to exist. I did manage to apply your patch
>> set on top of next-20160415, though.
>>
>> So... what testing did you do? ;-) I ran in
"Kani, Toshimitsu" writes:
>> I had dm-linear and md-raid0 support on my list of things to look at,
>> did you have raid0 in your plans?
>
> Yes, I hope to extend further and raid0 is a good candidate.
dm-flakey would allow more xfstests test cases to run. I'd say that's
more important than
Mike Snitzer writes:
> On Tue, Jun 14 2016 at 9:50am -0400,
> Jeff Moyer wrote:
>
>> "Kani, Toshimitsu" writes:
>>
>> >> I had dm-linear and md-raid0 support on my list of things to look at,
>> >> did you have raid0 in your plans?
>
Eric Wheeler writes:
> [+cc Mikulas Patocka, Jeff Moyer; Do either of you have any input on Lars'
> commentary related to patchwork #'s 9204125 and 7398411 and BZ#119841? ]
Sorry, I don't have any time to look at this right now.
Cheers,
Jeff
>
> On Tue, 19 Jul
Hi, Mike,
Mike Snitzer writes:
> Looking at Mikulas' wrapper API that you and hch are calling into
> question:
>
> For ARM it is using arch/arm64/mm/flush.c:arch_wb_cache_pmem().
> (And ARM does seem to be providing CONFIG_ARCH_HAS_PMEM_API.)
>
> Whereas x86_64 is using memcpy_flushcache() as pr
Dan Williams writes:
> When I read your patch I came away with the impression that ARM had
> not added memcpy_flushcache() yet and you were working around that
> fact. Now that I look, ARM *does* define memcpy_flushcache() and
> you're avoiding it. You use memcpy+arch_wb_pmem where arch_wb_pmem o
Jeff Moyer writes:
> Dan Williams writes:
>
>> When I read your patch I came away with the impression that ARM had
>> not added memcpy_flushcache() yet and you were working around that
>> fact. Now that I look, ARM *does* define memcpy_flushcache() and
>> you&
Jan Kara writes:
> On Tue 28-08-18 13:56:30, Mike Snitzer wrote:
>> On Tue, Aug 28 2018 at 3:50am -0400,
>> Jan Kara wrote:
>>
>> > On Mon 27-08-18 16:43:28, Kani, Toshi wrote:
>> > > On Mon, 2018-08-27 at 18:07 +0200, Jan Kara wrote:
>> > > > Hi,
>> > > >
>> > > > I've been analyzing why fst
Mike Snitzer writes:
> Until we properly add DAX support to dm-snapshot I'm afraid we really do
> need to tolerate this "regression". Since reality is the original
> support for snapshot of a DAX DM device never worked in a robust way.
Agreed.
-Jeff
--
dm-devel mailing list
dm-devel@redhat.co
Mikulas Patocka writes:
> On Thu, 30 Aug 2018, Jeff Moyer wrote:
>
>> Mike Snitzer writes:
>>
>> > Until we properly add DAX support to dm-snapshot I'm afraid we really do
>> > need to tolerate this "regression". Since reality is the original
29 matches
Mail list logo
