linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bart Van Assche <bart.vanassche@sandisk.com>
To: device-mapper development <dm-devel@redhat.com>,
	<linux-fsdevel@vger.kernel.org>, <linux-raid@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-scsi@vger.kernel.org>,
	<drbd-dev@lists.linbit.com>
Subject: Re: [dm-devel] [RFC PATCH 00/32] separate operations from flags in the bio/request structs
Date: Wed, 4 Nov 2015 08:49:00 -0800	[thread overview]
Message-ID: <563A36FC.6010001@sandisk.com> (raw)
In-Reply-To: <1446654807-6935-1-git-send-email-mchristi@redhat.com>

On 11/04/2015 08:32 AM, mchristi@redhat.com wrote:
> There are a couple new block layer commands we are trying to add support
> for in the near term:
>
> compare and write
> http://www.spinics.net/lists/target-devel/msg07826.html
>
> copy offload/extended copy/xcopy
> https://www.redhat.com/archives/dm-devel/2014-July/msg00070.html
>
> The problem is if we contine to add more commands we will have to one day
> extend the cmd_flags/bi_rw fields again. To prevent that, this patchset
> separates the operation (REQ_WRITE, REQ_DISCARD, REQ_WRITE_SAME, etc) from
> the flags (REQ_SYNC, REQ_QUIET, etc) in the bio and request structs. In the
> end of this set, we will have two fields bio->bi_op/request->op and
> bio->bi_rw/request->cmd_flags.
>
> The patches were made against Jens's linux-block tree's for-linus branch:
> https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git/log/?h=for-linus
> (last commit a22c4d7e34402ccdf3414f64c50365436eba7b93).
>
> I have done some basic testing for a lot of the drivers and filesystems,
> but I wanted to get comments before trying to track down more hardware/
> systems for testing.
>
>
> Known issues:
> - REQ_FLUSH is still a flag, but should probably be a operation.
>   For lower level drivers like SCSI where we only get a flush, it makes
> more sense to be a operation. However, upper layers like filesystems
> can send down flushes with writes, so it is more of a flag for them.
> I am still working on this.
>
> - There is a regression with the dm flakey target. It currently
> cannot corrupt the operation values.
>
> - The patchset is a little awkward. It touches so much code,
> but I wanted to maintain git bisectibility, so there is lots of compat code
> left around until the last patches where everyting is cleaned up.

Hello Mike,

If you have to touch submit_bio() and submit_bio_wait(), how about 
requiring the callers of these functions to set the cmd and flags 
arguments in the bio structure and to leave out the cmd and flags 
arguments from the submit_bio() and submit_bio_wait() functions ? A 
(compile tested only) patch that implements this idea is available at 
https://lkml.org/lkml/2014/6/2/173.

Bart.

  parent reply	other threads:[~2015-11-04 16:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-04 16:32 [RFC PATCH 00/32] separate operations from flags in the bio/request structs mchristi
2015-11-04 16:32 ` [PATCH 01/32] block/fs: add REQ_OP definitions mchristi
2015-11-04 16:32 ` [PATCH 02/32] block/fs/mm: prepare submit_bio_wait users for bi_rw split mchristi
2015-11-04 16:32 ` [PATCH 03/32] dio/btrfs: prep dio->submit_bio " mchristi
2015-11-04 16:32 ` [PATCH 04/32] block: prepare blkdev_issue_discard " mchristi
2015-11-04 16:33 ` [PATCH 05/32] drbd: prepare drbd " mchristi
2015-11-04 16:33 ` [PATCH 06/32] xen blkback: prepare " mchristi
2015-11-04 16:33 ` [PATCH 07/32] dm: " mchristi
2015-11-04 16:33 ` [PATCH 08/32] target: " mchristi
2015-11-04 16:33 ` [PATCH 09/32] btrfs: " mchristi
2015-11-04 16:49 ` Bart Van Assche [this message]
2015-11-04 16:53   ` [dm-devel] [RFC PATCH 00/32] separate operations from flags in the bio/request structs Mike Christie
2015-11-07 10:23     ` Christoph Hellwig
2015-11-11  7:53       ` Mike Christie
2015-11-11 11:28         ` Christoph Hellwig
2015-11-11 17:37           ` Mike Snitzer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=563A36FC.6010001@sandisk.com \
    --to=bart.vanassche@sandisk.com \
    --cc=dm-devel@redhat.com \
    --cc=drbd-dev@lists.linbit.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).