| Message ID | 1477728600-12938-24-git-send-email-tom.leiming@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, Oct 29, 2016 at 04:08:22PM +0800, Ming Lei wrote: > MD(especially raid1 and raid10) is a bit difficult to support > multipage bvec, so introduce this flag for not enabling multipage > bvec, then MD can still accept singlepage bvec only, and once > direct access to bvec table in MD and other fs/drivers are cleanuped, > the flag can be removed. BTRFS has the similar issue too. There is really no good reason for that. The RAID1 and 10 code really just needs some love to use the bio cloning infrastructure, bio iterators and generally recent bio apis. btrfs just needs a tiny little bit of help and I'll send patches soon. Having two different code path is just asking for trouble in the long run. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 29, 2016 at 11:29 PM, Christoph Hellwig <hch@infradead.org> wrote: > On Sat, Oct 29, 2016 at 04:08:22PM +0800, Ming Lei wrote: >> MD(especially raid1 and raid10) is a bit difficult to support >> multipage bvec, so introduce this flag for not enabling multipage >> bvec, then MD can still accept singlepage bvec only, and once >> direct access to bvec table in MD and other fs/drivers are cleanuped, >> the flag can be removed. BTRFS has the similar issue too. > > There is really no good reason for that. The RAID1 and 10 code really > just needs some love to use the bio cloning infrastructure, bio > iterators and generally recent bio apis. btrfs just needs a tiny little > bit of help and I'll send patches soon. That is very nice of you to do this cleanup, cool! I guess it still need a bit time, and hope that won't be the block for the whole patchset, :-) [linux-2.6-next]$git grep -n -E "bi_io_vec|bi_vcnt" ./fs/btrfs/ | wc -l 45 [linux-2.6-next]$git grep -n -E "bi_io_vec|bi_vcnt" ./drivers/md/ | grep raid | wc -l 54 > > Having two different code path is just asking for trouble in the long > run. Definitely, that flag is introduced just as a short-term solution. Thanks, Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index c47c358ba052..e4dd25361bd6 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -505,6 +505,7 @@ struct request_queue { #define QUEUE_FLAG_FUA 24 /* device supports FUA writes */ #define QUEUE_FLAG_FLUSH_NQ 25 /* flush not queueuable */ #define QUEUE_FLAG_DAX 26 /* device supports DAX */ +#define QUEUE_FLAG_NO_MP 27 /* multipage bvecs isn't ready */ #define QUEUE_FLAG_DEFAULT ((1 << QUEUE_FLAG_IO_STAT) | \ (1 << QUEUE_FLAG_STACKABLE) | \ @@ -595,6 +596,7 @@ static inline void queue_flag_clear(unsigned int flag, struct request_queue *q) #define blk_queue_secure_erase(q) \ (test_bit(QUEUE_FLAG_SECERASE, &(q)->queue_flags)) #define blk_queue_dax(q) test_bit(QUEUE_FLAG_DAX, &(q)->queue_flags) +#define blk_queue_no_mp(q) test_bit(QUEUE_FLAG_NO_MP, &(q)->queue_flags) #define blk_noretry_request(rq) \ ((rq)->cmd_flags & (REQ_FAILFAST_DEV|REQ_FAILFAST_TRANSPORT| \
MD(especially raid1 and raid10) is a bit difficult to support multipage bvec, so introduce this flag for not enabling multipage bvec, then MD can still accept singlepage bvec only, and once direct access to bvec table in MD and other fs/drivers are cleanuped, the flag can be removed. BTRFS has the similar issue too. Signed-off-by: Ming Lei <tom.leiming@gmail.com> --- include/linux/blkdev.h | 2 ++ 1 file changed, 2 insertions(+)