Re: [dm-devel] [PATCH 2/3] block: require write_same and discard requests align to logical block size

On Tue, Apr 12, 2016 at 09:01:35PM -0700, Darrick J. Wong wrote: > Make sure that the offset and length arguments that we're using to > construct WRITE SAME and DISCARD requests are actually aligned to the > logical block size. Failure to do this causes other errors in other > parts of the block

Re: [dm-devel] [PATCH v2 1/5] block: reinstate early return of -EOPNOTSUPP from blkdev_issue_discard

I don't really agree with the rationale, but I'm fine with reverting to it this late in the cycle, so: Acked-by: Christoph Hellwig <h...@lst.de> But looking at your slightly convoluted handling of the errors in dm-think, what do you think about splitting out these early checks into a se

Re: [dm-devel] [PATCH 2/5] block: make bio_inc_remaining() interface accessible again

run another instance of process_discard_cell_passdown. So I guess we'll have to live with this for now. I really don't like it very much, and the comments could use a massive improvement, but instead of duplicating the code let's just export the helper: Acked-by: Christoph Hellwig <h...@

Re: [dm-devel] [PATCH 5/5] dm thin: unroll issue_discard() to create longer discard bio chains

On Fri, May 06, 2016 at 05:36:58PM +0100, Joe Thornber wrote: > But the plugging and error handling are called from two places. > process_prepared_discard_passdown() and > passdown_double_checking_shared_status(). passdown_double_checking_shared_status is only called from

Re: [dm-devel] [PATCH 2/5] block: make bio_inc_remaining() interface accessible again

On Thu, May 05, 2016 at 11:54:22AM -0400, Mike Snitzer wrote: > Commit 326e1dbb57 ("block: remove management of bi_remaining when > restoring original bi_end_io") made bio_inc_remaining() private to bio.c > because the only use-case that made sense was confined to the > bio_chain() interface. > >

[dm-devel] [PING / RESEND] handling reservation conflicts in dm-mpath

Hannes sent this patch a bit more than a year ago, but it got silently dropped. When using the pNFS SCSI layout we can easily hit a failover "livelock" without it as the reservation conflicts on a newly detected device that doesn't have layouts yet, or after a fency will keep failing over from

[dm-devel] [PATCH] dm-mpath: always return reservation conflict

of any forward progress. And arguably a reservation conflict is an unexpected error, so we should be passing it upwards to allow the application to take appropriate steps. Signed-off-by: Hannes Reinecke <h...@suse.de> Acked-by: Christoph Hellwig <h...@lst.de> Tested-by: Christoph He

Re: [dm-devel] [PATCH] dm-mpath: always return reservation conflict

ping? On Tue, Aug 02, 2016 at 02:36:32PM +0200, Christoph Hellwig wrote: > From: Hannes Reinecke <h...@suse.de> > > If dm-mpath encounters an reservation conflict it should not fail the > path (as communication with the target is not affected) but should > rather retry on

Re: [dm-devel] [PATCH next] Btrfs: fix comparison in __btrfs_map_block()

On Sun, Jul 17, 2016 at 03:51:03PM -0500, Mike Christie wrote: > > > > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c > > index a69203a..6ee1e36 100644 > > --- a/fs/btrfs/volumes.c > > +++ b/fs/btrfs/volumes.c > > @@ -5533,7 +5533,7 @@ static int __btrfs_map_block(struct btrfs_fs_info > >

Re: [dm-devel] PR API fixes for multipathing

On Fri, Jul 15, 2016 at 03:03:54PM -0400, Martin K. Petersen wrote: > >>>>> "Christoph" == Christoph Hellwig <h...@lst.de> writes: > > Christoph> I was a bit overeager to thing ALL_TG_PT would solve all our > Christoph> multipathing woes in resp

[dm-devel] [PATCH 2/2] dm: call PR reserve/unreserve on each underlying device

ports' bit in SCSI, and let device mapper handle iterating over the device for each path and register it manually. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/md/dm.c | 85 +++-- 1 file changed, 70 insertions(+), 15 del

[dm-devel] PR API fixes for multipathing

I was a bit overeager to thing ALL_TG_PT would solve all our multipathing woes in respect to persistent reservation. Turns out that there are lots of possible setups where it doesn't work, and we'll have to ask device mapper to register all underlying devices instead. -- dm-devel mailing list

[dm-devel] [PATCH 1/2] sd: don't use the ALL_TG_PT bit for reservations

These only work if the we use the same initiator ID for all path, which might not be true if we use different protocols, or even just different HBAs. Instead dm-mpath will grow support to register all path manually later in this series. Signed-off-by: Christoph Hellwig <h...@lst.de> --- d

Re: [dm-devel] linux-next: Tree for Feb 2 (drivers/md/dm.c)

On Thu, Feb 02, 2017 at 01:29:16PM -0500, Mike Snitzer wrote: > Are you trying to say that this happens using a certain .config? > > Also, not sure why you didn't cc Christoph (or Jens) seeing as these > changes are _not_ staged in linux-next by linux-dm.git. No changes to dm caused this, it was

Re: [dm-devel] error propagation problem on xfs over dm stripe

On Tue, Jan 31, 2017 at 09:12:07PM -0600, Eric Sandeen wrote: > diff --git a/drivers/md/dm.c b/drivers/md/dm.c > index 3086da5..3555ba8 100644 > --- a/drivers/md/dm.c > +++ b/drivers/md/dm.c > @@ -808,7 +808,9 @@ static void dec_pending(struct dm_io *io, int error) > } else { >

Re: [dm-devel] error propagation problem on xfs over dm stripe

On Wed, Feb 01, 2017 at 09:33:51AM -0500, Mike Snitzer wrote: > > FYI, what we do both in the XFS buffer cache and the new direct I/O > > code is to use a > > > > cmpxchg(>error, 0, ret); > > > > in a similar situation, which should work here, too. > > What is the benefit? Faster

[dm-devel] [PATCH v4] dm: don't allow ioctls to targets that don't map to whole devices

it in for DM, and the exception is not very useful anyway. Signed-off-by: Christoph Hellwig <h...@lst.de> Acked-by: Mike Snitzer <snit...@redhat.com> --- drivers/md/dm.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/md/dm.c b/drivers/md/dm.c index

[dm-devel] [PATCH] dm: don't allow ioctls to targets that don't map to whole devices

to drag it in for DM, and the exception is not very useful anyway. Signed-off-by: Christoph Hellwig <h...@lst.de> Note: this should go into the block tree, as that's where scsi_verify_blk_ioctl becomes optional. --- drivers/md/dm.c | 13 - 1 file changed, 8 insertions(+), 5 del

Re: [dm-devel] [PATCH] dm: don't allow ioctls to targets that don't map to whole devices

On Fri, Feb 03, 2017 at 11:10:10AM +0100, Johannes Thumshirn wrote: > On 02/03/2017 11:06 AM, Christoph Hellwig wrote: >> .. at least for unprivilegued users. Before we called into the SCSI >> ioctl code to allow excemptions for a few SCSI passthrough ioctls, >> but

[dm-devel] [PATCH v3] dm: don't allow ioctls to targets that don't map to whole devices

it in for DM, and the exception is not very useful anyway. Signed-off-by: Christoph Hellwig <h...@lst.de> Acked-by: Mike Snitzer <snit...@redhat.com> --- drivers/md/dm.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/md/dm.c b/drivers/md/dm.c index

Re: [dm-devel] [PATCH v3] dm: don't allow ioctls to targets that don't map to whole devices

On Fri, Feb 03, 2017 at 11:39:22AM -0500, Mike Snitzer wrote: > I assume you meant for v3 to remove the newline? ;) I did. And I swear I did edit the file, but I guess the ammend didn't work. I guess it's time for the weekend.. I'll resend after I got some rest. -- dm-devel mailing list

Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

On Sun, Jan 22, 2017 at 06:19:24PM +, Matthew Wilcox wrote: > No, I mean a network filesystem like 9p or cifs or nfs. If the memcpy > is supposed to be performed by the backing device struct backing_dev has no relation to the DAX code. Even more so what's the point of doing a DAXish memcpy

Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

On Sun, Jan 22, 2017 at 03:43:09PM +, Matthew Wilcox wrote: > In the case of a network filesystem being used to communicate with > a different VM on the same physical machine, there is no backing > device, just a network protocol. Again, do you mean block device? For a filesystem that does

Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

On Sun, Jan 22, 2017 at 06:39:28PM +, Matthew Wilcox wrote: > Two guests on the same physical machine (or a guest and a host) have access > to the same set of physical addresses. This might be an NV-DIMM, or it might > just be DRAM (for the purposes of reducing guest overhead). The network

Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

On Sat, Jan 21, 2017 at 04:28:52PM +, Matthew Wilcox wrote: > Of course, there may not be a backing device either! s/backing device/block device/ ? If so fully agreed. I like the dax_ops scheme, but we should go all the way and detangle it from the block device. I already brought up this

[dm-devel] [PATCH 11/16] scsi: remove scsi_cmd_dma_pool

There is no need for GFP_DMA allocations of the scsi_cmnd structures themselves, all that might be DMAed to or from is the actual payload, or the sense buffers. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/scsi.c | 15 +-- 1 file changed, 1 insertion(

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

On Mon, Jan 23, 2017 at 08:39:44AM -0700, Jens Axboe wrote: > I'd like to get this in sooner rather than later, so I'll spend some > time reviewing and testing it start this week. I'm assuming you are > targeting 4.11 with this change, right? Yes. -- dm-devel mailing list dm-devel@redhat.com

Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

On Sun, Jan 22, 2017 at 09:30:23AM -0800, Dan Williams wrote: > So are you saying we need a way to go from a block_device inode to a > dax_device inode and then look up the dax_operations from there? > > A filesystem, if it so chooses, could mount on top of the dax_device > inode directly?

[dm-devel] [PATCH 03/16] block: allow specifying size for extra command data

This mirrors the blk-mq capabilities to allocate extra drivers-specific data behind struct request by setting a cmd_size field, as well as having a constructor / destructor for it. Signed-off-by: Christoph Hellwig <h...@lst.de> --- block/blk-core.c

[dm-devel] [PATCH 16/16] block: don't assign cmd_flags in __blk_rq_prep_clone

These days we have the proper flags set since request allocation time. Signed-off-by: Christoph Hellwig <h...@lst.de> --- block/blk-core.c | 1 - 1 file changed, 1 deletion(-) diff --git a/block/blk-core.c b/block/blk-core.c index fe5cc98..93a9e0b 100644 --- a/block/blk-core.c +++ b/blo

[dm-devel] [PATCH 07/16] scsi_dh_emc: switch to scsi_execute_req_flags()

d even if the device is quiesced. Signed-off-by: Hannes Reinecke <h...@suse.com> Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/device_handler/scsi_dh_emc.c | 247 +++--- 1 file changed, 56 insertions(+), 191 deletions(-) diff --git a/drivers/s

[dm-devel] [PATCH 08/16] scsi_dh_hp_sw: switch to scsi_execute_req_flags()

Signed-off-by: Hannes Reinecke <h...@suse.com> Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/device_handler/scsi_dh_hp_sw.c | 222 1 file changed, 65 insertions(+), 157 deletions(-) diff --git a/drivers/scsi/device_handler/scsi_dh_hp_sw

[dm-devel] [PATCH 14/16] block/bsg: move queue creation into bsg_setup_queue

Simply the boilerplate code needed for bsg nodes a bit. Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Johannes Thumshirn <jthumsh...@suse.de> --- block/bsg-lib.c | 21 +++-- drivers/scsi/scsi_transport_

[dm-devel] [PATCH 04/16] dm: remove incomple BLOCK_PC support

DM tries to copy a few fields around for BLOCK_PC requests, but given that no dm-target ever wires up scsi_cmd_ioctl BLOCK_PC can't actually be sent to dm. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/md/dm-rq.c | 16 1 file changed, 16 deletions(-) diff

Re: [dm-devel] [PATCH 05/16] dm: always defer request allocation to the owner of the request_queue

On Tue, Jan 24, 2017 at 11:39:51AM -0500, Mike Snitzer wrote: > Fair enough. Cc'ing Junichi just in case he sees anything we're > missing. Thanks, I'll wait for his repsonse before reposting with the few accumulated changes (including the dm cleanup). -- dm-devel mailing list

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

On Fri, Jan 27, 2017 at 09:11:14AM -0700, Jens Axboe wrote: > I've queued this up for 4.11. Since some of the patches had dependencies > on changes in master since for-4.11/block was forked, they are sitting > in a separate branch that has both for-4.11/block and v4.10-rc5 pulled > in first.

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

On Fri, Jan 27, 2017 at 09:21:46AM -0700, Jens Axboe wrote: > On 01/27/2017 09:17 AM, Christoph Hellwig wrote: > > On Fri, Jan 27, 2017 at 09:11:14AM -0700, Jens Axboe wrote: > >> I've queued this up for 4.11. Since some of the patches had dependencies > >> on chang

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

On Fri, Jan 27, 2017 at 09:27:02AM -0700, Jens Axboe wrote: > Feel free to repost it, I have no problem rebasing that branch as it's > standalone for now. Ok, I'll repost what I have right now, which is on top of a merge of your block/for-4.11/next and your for-next from this morning my time.

Re: [dm-devel] [PATCH 07/18] dm: always defer request allocation to the owner of the request_queue

On Fri, Jan 27, 2017 at 11:34:34AM -0500, Mike Snitzer wrote: > Noticed after further review that it seems a bit weird to have the non > blk-mq support in drivers calling blk_mq_rq_to_pdu(). But I'm not sure > a blk_rq_to_pdu() macro to blk_mq_rq_to_pdu() is the right thing. What > do you guys

[dm-devel] [PATCH 02/19] md: cleanup bio op / flags handling in raid1_write_request

No need for the local variables, the bio is still live and we can just assign the bits we want directly. Make me wonder why we can't assign all the bio flags to start with. Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Bart Van Assche <bart.vanass...@sandisk.com&

[dm-devel] [PATCH 01/19] block: add a op_is_flush helper

This centralizes the checks for bios that needs to be go into the flush state machine. Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Bart Van Assche <bart.vanass...@sandisk.com> Reviewed-by: Martin K. Petersen <martin.peter...@oracle.com> --- block/blk-core.

Re: [dm-devel] [PATCH 15/16] block: split scsi_request out of struct request

On Thu, Jan 26, 2017 at 11:12:51AM -0800, Bart Van Assche wrote: > Where does the '* 3' come from? I think that deserves a comment. > Additionally, this patch introduces a new warning when building with W=1: It's a magic factor copied from the old code :( That beeing said I really wonder if we

[dm-devel] [PATCH 15/18] scsi: allocate scsi_cmnd structures as part of struct request

Rely on the new block layer functionality to allocate additional driver specific data behind struct request instead of implementing it in SCSI itѕelf. Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Hannes Reinecke <h...@suse.com> --- drivers/scsi/hosts.c | 20 +--

[dm-devel] [PATCH 01/18] block: add a op_is_flush helper

This centralizes the checks for bios that needs to be go into the flush state machine. Signed-off-by: Christoph Hellwig <h...@lst.de> --- block/blk-core.c | 8 block/blk-mq-sched.c | 5 ++--- block/blk-mq.c | 4 ++-- drivers/md/bcache/request.c

[dm-devel] [PATCH 04/18] block: simplify blk_init_allocated_queue

, given that the request structure is zeroed on allocation. Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Hannes Reinecke <h...@suse.com> --- block/blk-core.c | 38 +++--- drivers/md/dm-rq.c | 3 ++- include/linux/blkdev.h | 3

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

Hi all, this series splits the support for SCSI passthrough commands from the main struct request used all over the block layer into a separate scsi_request structure that drivers that want to support SCSI passthough need to embedded as the first thing into their request-private data, similar to

[dm-devel] [PATCH 03/18] block: fix elevator init check

for a flush. Fix this by allowing to pass any block op and flags, and by checking for the flush flags in __get_request. Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Hannes Reinecke <h...@suse.com> --- block/blk-core.c | 26 -- 1 file changed,

[dm-devel] [PATCH 18/18] block: don't assign cmd_flags in __blk_rq_prep_clone

These days we have the proper flags set since request allocation time. Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Hannes Reinecke <h...@suse.com> --- block/blk-core.c | 1 - 1 file changed, 1 deletion(-) diff --git a/block/blk-core.c b/block/blk-core.c index 33c5d

[dm-devel] [PATCH 09/18] scsi_dh_emc: switch to scsi_execute_req_flags()

d even if the device is quiesced. Signed-off-by: Hannes Reinecke <h...@suse.com> Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/device_handler/scsi_dh_emc.c | 247 +++--- 1 file changed, 56 insertions(+), 191 deletions(-) diff --git a/drivers/s

[dm-devel] [PATCH 05/18] block: allow specifying size for extra command data

This mirrors the blk-mq capabilities to allocate extra drivers-specific data behind struct request by setting a cmd_size field, as well as having a constructor / destructor for it. Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Hannes Reinecke <h...@suse.com> --- bloc

[dm-devel] [PATCH 12/18] scsi: respect unchecked_isa_dma for blk-mq

that this switches to lazy allocation of the sense slab caches - the slab caches (not the actual allocations) won't be destroy until the scsi module is unloaded instead of keeping track of hosts using them. Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Hannes Reinecke <h...@suse.com>

[dm-devel] [PATCH 11/18] scsi: remove gfp_flags member in scsi_host_cmd_pool

-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Johannes Thumshirn <jthumsh...@suse.de> --- drivers/scsi/scsi.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c index 75455d4..0f93892 100644 --- a/drivers/scsi/scsi.c +

[dm-devel] [PATCH 10/18] scsi_dh_hp_sw: switch to scsi_execute_req_flags()

Signed-off-by: Hannes Reinecke <h...@suse.com> Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/device_handler/scsi_dh_hp_sw.c | 222 1 file changed, 65 insertions(+), 157 deletions(-) diff --git a/drivers/scsi/device_handler/scsi_dh_hp_sw

[dm-devel] [PATCH 07/18] dm: always defer request allocation to the owner of the request_queue

in the block layer greatly simplifies the dm-rq and mpath code, and should also make arbitrary combinations of SQ and MQ devices with SQ or MQ device mapper tables easily possible as a further step. Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Hannes Reinecke <h...@suse.com&

[dm-devel] [PATCH 13/18] scsi: remove scsi_cmd_dma_pool

There is no need for GFP_DMA allocations of the scsi_cmnd structures themselves, all that might be DMAed to or from is the actual payload, or the sense buffers. Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Hannes Reinecke <h...@suse.com> --- drivers/scsi

[dm-devel] [PATCH 08/18] scsi_dh_rdac: switch to scsi_execute_req_flags()

d even if the device is quiesced. Signed-off-by: Hannes Reinecke <h...@suse.com> Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/device_handler/scsi_dh_rdac.c | 174 + 1 file changed, 51 insertions(+), 123 deletions(-) diff --git a/drivers/s

[dm-devel] [PATCH 02/18] md: cleanup bio op / flags handling in raid1_write_request

No need for the local variables, the bio is still live and we can just assigned the bits we want directly. Make me wonder why we can't assign all the bio flags to start with. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/md/raid1.c | 7 ++- 1 file changed, 2 insertions

Re: [dm-devel] [PATCH 1/1] dm-zoned: Zoned block device target

On Thu, Feb 09, 2017 at 01:18:49PM +0900, Damien Le Moal wrote: > + > +/* > + * Target BIO completion. > + */ > +static inline void dmz_bio_end(struct bio *bio, int err) > +{ > + struct dm_zone_bioctx *bioctx = > + dm_per_bio_data(bio, sizeof(struct dm_zone_bioctx)); > + > + if

Re: [dm-devel] [PATCH 1/2] Don't blacklist nvme

On Tue, Feb 14, 2017 at 06:00:23PM -0500, Keith Busch wrote: > Good point. I was unknowingly running with CONFIG_SCSI_DH disabled, > and blissfully unaware of its existence! After enabling that option, > I see what you mean. Someone needs to fix that crash ASAP. I though Hannes had patches for

Re: [dm-devel] [PATCH 01/16] block: fix elevator init check

On Tue, Jan 24, 2017 at 08:06:39AM -0700, Jens Axboe wrote: > We check for REQ_PREFLUSH | REQ_FUA in so many places though, might not > be a bad idea to keep the helper but just make it take the opf and fix > up the other locations too. The fact that PREFLUSH|FUA is the magic to > check for is

Re: [dm-devel] [PATCH 00/13] dax, pmem: move cpu cache maintenance to libnvdimm

On Mon, Jan 23, 2017 at 09:14:04AM -0800, Dan Williams wrote: > The use case that we have now is distinguishing volatile vs persistent > memory (brd vs pmem). brd is a development tool, so until we have other reasons for this abstraction (which I'm pretty sure will show up rather sooner than

Re: [dm-devel] [PATCH 05/16] dm: always defer request allocation to the owner of the request_queue

On Tue, Jan 24, 2017 at 05:05:39AM -0500, Mike Snitzer wrote: > possible and is welcomed cleanup. The only concern I have is that using > get_request() for the old request_fn request_queue eliminates the > guaranteed availability of requests to allow for forward progress (on > path failure or for

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 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,

Re: [dm-devel] [PATCH 37/45] drivers: use req op accessor

On Wed, Aug 03, 2016 at 07:30:29PM -0500, Shaun Tancheff wrote: > I think the translation in loop.c is suspicious here: > > "if use DIO && not (a flush_flag or discard_flag)" > should translate to: > "if use DIO && not ((a flush_flag) || op == discard)" > > But in the patch I read: >

Re: [dm-devel] [PATCH 2/3] block, dm-crypt, btrfs: Introduce bio_flags()

he <bart.vanass...@sandisk.com> > Cc: Mike Christie <mchri...@redhat.com> > Cc: Chris Mason <c...@fb.com> (maintainer:BTRFS FILE SYSTEM) > Cc: Josef Bacik <jba...@fb.com> (maintainer:BTRFS FILE SYSTEM) > Cc: Mike Snitzer <snit...@redhat.com> > Cc: Christoph Hel

Re: [dm-devel] [PATCH 2/3] block, dm-crypt, btrfs: Introduce bio_flags()

Ok, looks fine after reading the next patch: Reviewed-by: Christoph Hellwig <h...@lst.de> -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] dm-mpath: Handling SCSI-3 PR RELEASE in multi-controller environment

On Thu, Sep 22, 2016 at 04:14:50PM +0800, jiangyiwen wrote: > I briefly reviewed the PR API. If I understand correctly, a bunch of PR > dedicated operations (pr_ops) are defined in block_device_operations, which > includes register, reserve, release, preempt and clear operations. But among > these

Re: [dm-devel] dm-mpath: always return reservation conflict

On Thu, Sep 29, 2016 at 11:01:33AM -0400, Mike Snitzer wrote: > I've elected to just take this change for 4.9. Please see: > https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.9=8ff232c1a819c2e98d85974a3bff0b7b8e2970ed Thanks Mike. If any problems show up I

Re: [dm-devel] [PATCH] scsi: replace wrong device handler name for CLARiiON arrays

On Sun, Oct 09, 2016 at 07:21:45AM +0800, James Bottomley wrote: > Actually, should we replace? Aren't there older arrays still bearing > the clariion name, so we should have these entries in addition? The changed string isn't the inquiry vendor string, but the DH driver name it is mapped to.

Re: [dm-devel] dm-mpath: Handling SCSI-3 PR RELEASE in multi-controller environment

Hi Yibin, >>> - For reserve/query/preempt/clear, we should return success once an >>> iteration returns successfully. >> That's what the dm_grab_bdev_for_ioctl path does. > > If I understand correctly, dm_grab_bdev_for_ioctl() select a working path, > and > pr_*() uses that path to do

Re: [dm-devel] device mapper and the BLKFLSBUF ioctl

I think the right fix is to kill off the BLKFLSBUF special case in brd. Yes, it break compatibility - but in this case the compatibility breaks more than it helps. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel

Re: [dm-devel] [PATCH 07/12] dm: use bvec iterator helpers to implement .get_page and .next_page

> Hi Alasdair, Mike, Christoph and anyone, > > Could you give this one a review? It looks nice, but I don't understand the code anywhere near well enough to review it. We'll need someone from the DM to look over it. -- dm-devel mailing list dm-devel@redhat.com

Re: [dm-devel] [PATCH 00/60] block: support multipage bvec

Hi Ming, can you send a first patch just doing the obvious cleanups like converting to bio_add_page and replacing direct poking into the bio with the proper accessors? That should help reducing the actual series to a sane size, and it should also help to cut down the Cc list. -- dm-devel

Re: [dm-devel] REQ_OP for zeroing, was Re: [PATCH 1/4] brd: handle misaligned discard

[adding Chaitanya to Cc] On Fri, Oct 28, 2016 at 07:43:41AM -0400, Mikulas Patocka wrote: > We could detect if the REQ_OP_WRITE_SAME command contains all zeroes and > if it does, turn it into "Write Zeroes" or TRIM command (if the device > guarantees zeroing on trim). If it doesn't contain all

Re: [dm-devel] [PATCH 09/60] dm: dm.c: replace 'bio->bi_vcnt == 1' with !bio_multiple_segments

On Sat, Oct 29, 2016 at 04:08:08PM +0800, Ming Lei wrote: > Avoid to access .bi_vcnt directly, because it may be not what > the driver expected any more after supporting multipage bvec. > > Signed-off-by: Ming Lei It would be really nice to have a comment in the code why

[dm-devel] REQ_OP for zeroing, was Re: [PATCH 1/4] brd: handle misaligned discard

On Wed, Oct 26, 2016 at 05:46:11PM -0400, Mikulas Patocka wrote: > I think the proper thing would be to move "discard_zeroes_data" flag into > the bio itself - there would be REQ_OP_DISCARD and REQ_OP_DISCARD_ZERO - > and if the device doesn't support REQ_OP_DISCARD_ZERO, it rejects the bio >

Re: [dm-devel] trouble with generic/081

On Thu, Dec 15, 2016 at 10:16:23AM +0100, Zdenek Kabelac wrote: > So let me explain the logic behind this 'amazingly stupid' idea. And that logic doesn't make any sense at all. invibly unmounting a file system behind the users back is actively harmful, as it is contradicting the principle of

Re: [dm-devel] trouble with generic/081

On Thu, Dec 15, 2016 at 05:36:50PM +1100, Dave Chinner wrote: > Yup, same here. My local patch is this: I have a sleep 1 before the unmount. To be honest this lvm behavior of auto-unmounting on error seems like a huge mess, I wonder if there is a way to disable it? Even on a production system

[dm-devel] [PATCH 01/15] virtio_blk: avoid DMA to stack for the sense buffer

that this includes running tools like hdparm even when the host does not have SCSI passthrough enabled. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/block/virtio_blk.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio

[dm-devel] [PATCH 06/15] scsi_dh_rdac: switch to scsi_execute_req_flags()

d even if the device is quiesced. Signed-off-by: Hannes Reinecke <h...@suse.com> Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/device_handler/scsi_dh_rdac.c | 174 + 1 file changed, 51 insertions(+), 123 deletions(-) diff --git a/drivers/s

[dm-devel] [PATCH 13/15] scsi: allocate scsi_cmnd structures as part of struct request

Rely on the new block layer functionality to allocate additional driver specific data behind struct request instead of implementing it in SCSI itѕelf. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/hosts.c | 20 +-- drivers/scsi/scsi.c

[dm-devel] [PATCH 03/15] block: simplify blk_init_allocated_queue

, given that the request structure is zeroed on allocation. Signed-off-by: Christoph Hellwig <h...@lst.de> --- block/blk-core.c | 38 +++--- drivers/md/dm-rq.c | 3 ++- include/linux/blkdev.h | 3 +-- 3 files changed, 18 insertions(+), 26 deletions(-)

[dm-devel] [PATCH 11/15] scsi: remove scsi_cmd_dma_pool

There is no need for GFP_DMA allocations of the scsi_cmnd structures themselves, all that might be DMAed to or from is the actual payload, or the sense buffers. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/scsi.c | 15 +-- 1 file changed, 1 insertion(

[dm-devel] [PATCH 09/15] scsi: remove gfp_flags member in scsi_host_cmd_pool

-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/scsi.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c index 75455d4..0f93892 100644 --- a/drivers/scsi/scsi.c +++ b/drivers/scsi/scsi.c @@ -105,7 +105,6 @@

[dm-devel] [PATCH 07/15] scsi_dh_emc: switch to scsi_execute_req_flags()

d even if the device is quiesced. Signed-off-by: Hannes Reinecke <h...@suse.com> Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/device_handler/scsi_dh_emc.c | 247 +++--- 1 file changed, 56 insertions(+), 191 deletions(-) diff --git a/drivers/s

Re: [dm-devel] [PATCH 05/15] dm: remove incomple BLOCK_PC support

On Wed, Jan 11, 2017 at 08:09:37PM -0500, Mike Snitzer wrote: > I'm not following your reasoning. > > dm_blk_ioctl calls __blkdev_driver_ioctl and will call scsi_cmd_ioctl > (sd_ioctl -> scsi_cmd_blk_ioctl -> scsi_cmd_ioctl) if DM's underlying > block device is a scsi device. Yes, it it does.

Re: [dm-devel] [PATCH 14/15] block/bsg: move queue creation into bsg_setup_queue

On Wed, Jan 11, 2017 at 05:01:22PM -0500, Mike Snitzer wrote: > But I've seen you reference the need to stop multipath from allocating > its own requests. Are you referring to old request_fn request-based > multipath's clone_old_rq:alloc_old_clone_request? Yes, that one is the issue. It

Re: [dm-devel] [PATCH 05/15] dm: remove incomple BLOCK_PC support

On Thu, Jan 12, 2017 at 05:28:45PM -0500, Mike Snitzer wrote: > What is "incomplete" about request-based DM's BLOCK_PC support? BLOCK_PC requests are always aomething issued by the driver itself (for a broad defintion of the driver, aka everything under the block layer that works together is a

Re: [dm-devel] [PATCH 14/15] block/bsg: move queue creation into bsg_setup_queue

On Wed, Jan 11, 2017 at 09:56:01AM +0100, Johannes Thumshirn wrote: > I'll dig it up and RFC post it. It's currently untested though as I > currently don't have a SMP capable SAS HBA here. > > Do you have an mptXsas available? Unfortunately not. But I think Hannes has, he has recently played

Re: [dm-devel] [PATCH 01/15] virtio_blk: avoid DMA to stack for the sense buffer

On Wed, Jan 11, 2017 at 09:26:46AM +0100, Johannes Thumshirn wrote: > Isn't that one already queued in Jens' tree? Yes, it's now queued up. Patch 2 was submitted as well and should hopefully go into the next 4.10 RC. -- dm-devel mailing list dm-devel@redhat.com

Re: [dm-devel] [PATCH 14/15] block/bsg: move queue creation into bsg_setup_queue

On Wed, Jan 11, 2017 at 09:59:17AM +0100, Hannes Reinecke wrote: > I'd advocate to discuss this at LSF. > Now that Mike moved the bio-based mpath stuff back in things got even > more complex. Yeah. If we'd _only_ have bio based support it would simplify things a lot, but as a third parallel path

Re: [dm-devel] [PATCH 14/15] block/bsg: move queue creation into bsg_setup_queue

On Wed, Jan 11, 2017 at 09:42:44AM +0100, Johannes Thumshirn wrote: > On Tue, Jan 10, 2017 at 04:06:19PM +0100, Christoph Hellwig wrote: > > Simply the boilerplate code needed for bsg nodes a bit. > > > > Signed-off-by: Christoph Hellwig <h...@lst.de> > > --- &

[dm-devel] [PATCH 04/15] block: allow specifying size for extra command data

This mirrors the blk-mq capabilities to allocate extra drivers-specific data behind struct request by setting a cmd_size field, as well as having a constructor / destructor for it. Signed-off-by: Christoph Hellwig <h...@lst.de> --- block/blk-core.c

[dm-devel] [PATCH 15/15] block: split scsi_request out of struct request

And require all drivers that want to support BLOCK_PC to allocate it as the first thing of their private data. To support this the legacy IDE and BSG code is switched to set cmd_size on their queues to let the block layer allocate the additional space. Signed-off-by: Christoph Hellwig &l

[dm-devel] [PATCH 05/15] dm: remove incomple BLOCK_PC support

DM tries to copy a few fields around for BLOCK_PC requests, but given that no dm-target ever wires up scsi_cmd_ioctl BLOCK_PC can't actually be sent to dm. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/md/dm-rq.c | 16 1 file changed, 16 deletions(-) diff

[dm-devel] [PATCH 12/15] scsi: remove __scsi_alloc_queue

Instead do an internal export of __scsi_init_queue for the transport classes that export BSG nodes. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/scsi_lib.c | 19 --- drivers/scsi/scsi_transport_fc.c| 6 -- driver

[dm-devel] [PATCH 10/15] scsi: respect unchecked_isa_dma for blk-mq

that this switches to lazy allocation of the sense slab caches - the slab caches (not the actual allocations) won't be destroy until the scsi module is unloaded instead of keeping track of hosts using them. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/scsi/hosts.c | 4 driver

Re: [dm-devel] trouble with generic/081

On Fri, Jan 06, 2017 at 09:46:00AM +1100, Dave Chinner wrote: > And my 2c worth on the "lvm unmounting filesystems on error" - stop > it, now. It's the wrong thing to do, and it makes it impossible for > filesystems to handle the error and recover gracefully when > possible. It's causing way more

Re: [dm-devel] trouble with generic/081

On Mon, Jan 09, 2017 at 03:22:00PM +0100, Zdenek Kabelac wrote: > lvm2 will initiate lazy umount of ALL thin devices from a thin-pool > when it gets about 95% fullness (so it's a bit sooner then 100% > with still some 5% 'free-space'. Yes, and we want this not to be done. Not for XFS and not

  1   2   3   4   5   6   7   8   9   10   >