Messages in this thread |  | | Subject | Re: [PATCH RFC 1/3] block: Add support for REQ_OP_ASSIGN_RANGE operation | From | Kirill Tkhai <> | Date | Thu, 19 Dec 2019 14:07:16 +0300 |
| |
Hi, Martin!
On 19.12.2019 06:03, Martin K. Petersen wrote: > > Hi Kirill! > >> The patch adds a new blkdev_issue_assign_range() primitive, which is >> rather similar to existing blkdev_issue_{*} api. Also, a new queue >> limit.max_assign_range_sectors is added. > > I am not so keen on the assign_range name. What's wrong with "allocate"?
REQ_OP_ALLOCATE_RANGE seemed for me as looking very long for the reviewers. And I found that there is no an abbreviation of operations name in enum req_opf, so REQ_OP_ALLOC_RANGE won't look good. Thus, I found a replacement.
But in case of REQ_OP_ALLOCATE_RANGE length is OK for people, there is no a problem to choose it.
> But why introduce a completely new operation? Isn't this essentially a > write zeroes with BLKDEV_ZERO_NOUNMAP flag set? > > If the zeroing aspect is perceived to be a problem we could add a > BLKDEV_ZERO_ALLOCATE flag (or BLKDEV_ZERO_ANCHOR since that's the > terminology used in SCSI).
Hm. BLKDEV_ZERO_NOUNMAP is used in __blkdev_issue_write_zeroes() only. So, do I understand right that we should the below two?:
1)Introduce a new flag BLKDEV_ZERO_ALLOCATE for blkdev_issue_write_zeroes(). 2)Introduce a new flag REQ_NOZERO in enum req_opf.
Won't this confuse a reader that we have blkdev_issue_write_zeroes(), which does not write zeroes sometimes? Maybe we should rename blkdev_issue_write_zeroes() in some more generic name?
Thanks, Kirill
|  |