Re: [dm-devel] [RFC PATCH 00/32] separate operations from flags in the bio/request structs

From: Bart Van Assche
Date: Wed Nov 04 2015 - 11:49:15 EST

On 11/04/2015 08:32 AM, mchristi@xxxxxxxxxx wrote:
There are a couple new block layer commands we are trying to add support
for in the near term:

compare and write

copy offload/extended copy/xcopy

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

The patches were made against Jens's linux-block tree's for-linus branch:
(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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at