Re: [PATCH RESEND v6 1/9] pagemap: Introduce ->memory_failure()

2021-08-23 Thread h...@lst.de
On Wed, Aug 18, 2021 at 10:10:51AM -0700, Dan Williams wrote: > > Sounds like a nice solution. I think I can add an is_notify_supported() > > interface in dax_holder_ops and check it when register dax_holder. > > Shouldn't the fs avoid registering a memory failure handler if it is > not

Re: [dm-devel] [PATCH 05/11] block: get rid of the trace rq insert wrapper

2020-07-07 Thread h...@lst.de
On Fri, Jul 03, 2020 at 11:29:25PM +, Chaitanya Kulkarni wrote: > Christoph, > > On 6/29/20 4:44 PM, Chaitanya Kulkarni wrote: > > Get rid of the wrapper for trace_block_rq_insert() and call the function > > directly. > > > > Signed-off-by: Chaitanya Kulkarni > > --- > > Can we re-consider

Re: [dm-devel] [PATCH 12/15] block: merge blk_types.h into bio.h

2017-05-19 Thread h...@lst.de
On Thu, May 18, 2017 at 02:25:52PM +, Bart Van Assche wrote: > On Thu, 2017-05-18 at 15:18 +0200, Christoph Hellwig wrote: > > We've cleaned up our headers sufficiently that we don't need this split > > anymore. > > Hello Christoph, > > Request-based drivers need the structure definitions

Re: [dm-devel] [PATCH 25/27] block: remove the discard_zeroes_data flag

2017-05-11 Thread h...@lst.de
On Wed, May 10, 2017 at 09:50:35PM -0700, Nicholas A. Bellinger wrote: > 1) Expose a block_device or request_queue bit to signal 'real LBPRZ' > support up to IBLOCK, in order to maintain SCSI target feature > compatibility. No way. If you want to zero use REQ_OP_WRITE_ZEROES.. -- dm-devel

Re: [dm-devel] [PATCH 25/27] block: remove the discard_zeroes_data flag

2017-05-10 Thread h...@lst.de
On Mon, May 08, 2017 at 11:46:14PM -0700, Nicholas A. Bellinger wrote: > That said, simply propagating up q->limits.max_write_zeroes_sectors as > dev_attrib->unmap_zeroes_data following existing code still looks like > the right thing to do. It is not. Martin has decoupled write same/zeroes

Re: [dm-devel] [PATCH 25/27] block: remove the discard_zeroes_data flag

2017-05-07 Thread h...@lst.de
On Tue, May 02, 2017 at 08:33:15PM -0700, Nicholas A. Bellinger wrote: > The larger target/iblock conversion patch looks like post v4.12 material > at this point, so to avoid breakage wrt to existing LBPRZ behavior, I'll > plan to push the following patch post -rc1. I don't think this is safe.

Re: [dm-devel] [PATCH 25/27] block: remove the discard_zeroes_data flag

2017-05-02 Thread h...@lst.de
On Tue, May 02, 2017 at 12:16:13AM -0700, Nicholas A. Bellinger wrote: > Or, another options is use bdev_write_zeroes_sectors() to determine when > dev_attrib->unmap_zeroes_data should be set. Yes, that in combination with your patch to use bdev_write_zeroes_sectors for zeroing from write same

Re: [dm-devel] small dm mpath cleanups

2017-04-27 Thread h...@lst.de
On Wed, Apr 26, 2017 at 06:41:27PM +, Bart Van Assche wrote: > On Wed, 2017-04-26 at 09:40 +0200, Christoph Hellwig wrote: > > this series has some prep patches for my work to have proper, type > > checked block errors codes. One fallout of that is that we need to > > get rid of how dm

Re: [dm-devel] [PATCH 02/23] block: remove the blk_execute_rq return value

2017-04-19 Thread h...@lst.de
On Wed, Apr 19, 2017 at 09:07:45PM +, Bart Van Assche wrote: > > + blk_execute_rq(or->request->q, NULL, or->request, 0); > > + error = or->request ? -EIO : 0; > > Hello Christoph, > > Did you perhaps intend or->request->errors instead of or->request? Yes, thanks. -- dm-devel mailing

Re: [dm-devel] blk-mq: remove the error argument to blk_mq_complete_request

2017-04-19 Thread h...@lst.de
On Tue, Apr 18, 2017 at 10:50:18PM +, Bart Van Assche wrote: > On Tue, 2017-04-18 at 08:52 -0700, Christoph Hellwig wrote: > > Now that we always have a ->complete callback we can remove the direct > > call to blk_mq_end_request, as well as the error argument to > > blk_mq_complete_request. >

Re: [dm-devel] block: add a error_count field to struct request

2017-04-19 Thread h...@lst.de
On Tue, Apr 18, 2017 at 10:57:11PM +, Bart Van Assche wrote: > Both blk-mq and the traditional block layer support a .cmd_size field to > make the block layer core allocate driver-specific data at the end of struct > request. Could that mechanism have been used for the error_count field? It

Re: [dm-devel] scsi: introduce a new result field in struct scsi_request

2017-04-19 Thread h...@lst.de
On Tue, Apr 18, 2017 at 10:34:20PM +, Bart Van Assche wrote: > Did you perhaps intend "req->result" instead of "rq->result"? Yes. > Did you intend "war" or is that perhaps a typo? I'll fix the comment. > > trace_scsi_dispatch_cmd_done(cmd); > > - blk_mq_complete_request(cmd->request,

Re: [dm-devel] block: remove the blk_execute_rq return value

2017-04-19 Thread h...@lst.de
On Tue, Apr 18, 2017 at 10:24:15PM +, Bart Van Assche wrote: > On Tue, 2017-04-18 at 08:52 -0700, Christoph Hellwig wrote: > > diff --git a/drivers/block/paride/pd.c b/drivers/block/paride/pd.c > > index b05e151c9b38..82c6d02193ae 100644 > > --- a/drivers/block/paride/pd.c > > +++

Re: [dm-devel] [PATCH 02/25] block: remove the blk_execute_rq return value

2017-04-18 Thread h...@lst.de
On Mon, Apr 17, 2017 at 10:01:09AM -0600, Jens Axboe wrote: > Are you respinning this series for 4.12? Yes, I think I got enough feedback by now to resend it. I'll try to get it out today. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [PATCH 01/25] remove the mg_disk driver

2017-04-14 Thread h...@lst.de
On Thu, Apr 13, 2017 at 07:58:13PM +, Bart Van Assche wrote: > Should the person who submitted this driver be CC-ed for this patch (unsik > Kim )? Yes, he should. And in fact he was when I sent this patch out separately a little earlier, I just included it in this series

Re: [dm-devel] [PATCH 12/23] sd: handle REQ_UNMAP

2017-03-30 Thread h...@lst.de
On Thu, Mar 30, 2017 at 11:28:32AM -0400, Martin K. Petersen wrote: > "h...@lst.de" <h...@lst.de> writes: > > Christoph, > > > On Tue, Mar 28, 2017 at 04:48:55PM +, Bart Van Assche wrote: > >> > if (sdp->no_write_sam

Re: [dm-devel] [PATCH 23/23] block: remove the discard_zeroes_data flag

2017-03-30 Thread h...@lst.de
On Thu, Mar 30, 2017 at 11:29:29AM -0400, Martin K. Petersen wrote: > "h...@lst.de" <h...@lst.de> writes: > > > Jens, any opinion? I'd like to remove it too, but I fear it might > > break things. We could deprecate it first with a warning when read > >

Re: [dm-devel] [PATCH 23/23] block: remove the discard_zeroes_data flag

2017-03-30 Thread h...@lst.de
On Tue, Mar 28, 2017 at 05:00:48PM +, Bart Van Assche wrote: > > It seems to me like the documentation in Documentation/ABI/testing/sysfs-block > and the above code are not in sync. I think the above code will cause reading > from the discard_zeroes_data attribute to return an empty string

Re: [dm-devel] [PATCH 12/23] sd: handle REQ_UNMAP

2017-03-30 Thread h...@lst.de
On Tue, Mar 28, 2017 at 04:48:55PM +, Bart Van Assche wrote: > > if (sdp->no_write_same) > > return BLKPREP_INVALID; > > if (sdkp->ws16 || sector > 0x || nr_sectors > 0x) > > Users can change the provisioning mode from user space fromĀ SD_LBP_WS16 into >

Re: [dm-devel] [PATCH 11/23] block_dev: use blkdev_issue_zerout for hole punches

2017-03-30 Thread h...@lst.de
On Tue, Mar 28, 2017 at 04:50:47PM +, Bart Van Assche wrote: > On Thu, 2017-03-23 at 10:33 -0400, Christoph Hellwig wrote: > > This gets us support for non-discard efficient write of zeroes (e.g. NVMe) > > and preparse for removing the discard_zeroes_data flag. > > Hello Christoph, > >

Re: [dm-devel] split scsi passthrough fields out of struct request V2

2017-01-28 Thread h...@lst.de
On Fri, Jan 27, 2017 at 09:27:53PM +, Bart Van Assche wrote: > Have you considered to convert all block drivers to the new > approach and to get rid of request.special? If so, do you already > have plans to start working on this? I'm namely wondering wheter I > should start working on this

Re: [dm-devel] split scsi passthrough fields out of struct request V2

2017-01-26 Thread h...@lst.de
On Thu, Jan 26, 2017 at 11:57:36AM -0700, Jens Axboe wrote: > It's against my for-4.11/block, which you were running under Christoph's > patches. Maybe he's using an older version? In any case, should be > pretty trivial for you to hand apply. Just ensure that .flags is set to > 0 for the common