[PATCH 2/4] md: introduce bio_clone_slow_mddev_partial()

2017-02-04 Thread Ming Lei
In raid1/raid10, most users of bio_clone_mddev() need bio_trim() too, that means only part of the bio is required to be cloned, and not necessary to clone the whole bio each time, and it is just enough to clone the specified bvecs range. So this patch introduces bio_clone_slow_mddev_partial() to i

[PATCH 1/4] block: introduce bio_clone_bioset_partial()

2017-02-04 Thread Ming Lei
md still need bio clone(not the fast version) for behind write, and it is more efficient to use bio_clone_bioset_partial(). The idea is simple and just copy the bvecs range specified from parameters. Signed-off-by: Ming Lei --- block/bio.c | 61 +-

[PATCH 3/4] md/raid1: use bio_clone_slow_mddev_partial in case of write behind

2017-02-04 Thread Ming Lei
Write behind need to replace pages in bio's bvecs, and we have to clone a fresh bio with new bvec table, so use the introduced bio_clone_slow_mddev_partial() for it. For other bio_clone_mddev() cases, we will use fast clone since they don't need to touch bvec table. Signed-off-by: Ming Lei ---

[PATCH 4/4] md: fast clone bio in bio_clone_mddev()

2017-02-04 Thread Ming Lei
Firstly bio_clone_mddev() is used in raid normal I/O and isn't in resync I/O path. Secondly all the direct access to bvec table in raid happens on resync I/O except for write behind of raid1, in which we still use bio_clone() for allocating new bvec table. So this patch replaces bio_clone() with

[PATCH 0/4] md: use bio_clone_fast()

2017-02-04 Thread Ming Lei
Hi, This patches replaces bio_clone() with bio_fast_clone() in bio_clone_mddev() because: 1) bio_clone_mddev() is used in raid normal I/O and isn't in resync I/O path, and all the direct access to bvec table in raid happens on resync I/O only except for write behind of raid1. Write behind is trea

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

2017-02-04 Thread Jens Axboe
On 02/04/2017 02:45 AM, Christoph Hellwig wrote: > .. at least for unprivileged users. Before we called into the SCSI > ioctl code to allow excemptions for a few SCSI passthrough ioctls, > but this is pretty unsafe and except for this call dm knows nothing > about SCSI ioctls. > > As the SCSI ioc

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

2017-02-04 Thread Christoph Hellwig
.. at least for unprivileged users. Before we called into the SCSI ioctl code to allow excemptions for a few SCSI passthrough ioctls, but this is pretty unsafe and except for this call dm knows nothing about SCSI ioctls. As the SCSI ioctl code is now optional, we really don't want to drag it in f

Re: [REGRESSION v4.10-rc1] blkdev_issue_zeroout() returns -EREMOTEIO on the first call for SCSI device that doesn't support WRITE SAME

2017-02-04 Thread Christoph Hellwig
On Fri, Feb 03, 2017 at 08:17:10PM -0700, Jens Axboe wrote: > We're at (almost) -rc7 time, we have to do more than hand wave about > this. What's the plan for 4.10 final? I'll send your a fix to revert the async write same changes for now, as suggested in the last mail from me.