From: "Martin K. Petersen" <martin.petersen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> To: Bart Van Assche <Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> Cc: "axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org" <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>, "linux-raid-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-raid-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "martin.petersen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org" <martin.petersen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>, "philipp.reisner-63ez5xqkn6DQT0dZR+AlfA@public.gmane.org" <philipp.reisner-63ez5xqkn6DQT0dZR+AlfA@public.gmane.org>, "linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" <dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "lars.ellenberg-63ez5xqkn6DQT0dZR+AlfA@public.gmane.org" <lars.ellenberg-63ez5xqkn6DQT0dZR+AlfA@public.gmane.org>, "shli-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" <shli-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, "hch-jcswGhMUV9g@public.gmane.org" <hch-jcswGhMUV9g@public.gmane.org>, "agk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" <agk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "drbd-dev-cunTk1MwBs8qoQakbn7OcQ@public.gmane.org" <drbd-dev-cunTk1MwBs8qoQakbn7OcQ@public.gmane.org> Subject: Re: [PATCH 03/23] sd: implement REQ_OP_WRITE_ZEROES Date: Wed, 29 Mar 2017 22:25:33 -0400 [thread overview] Message-ID: <yq1o9wj4i1u.fsf@oracle.com> (raw) In-Reply-To: <1490726988.2573.16.camel-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> (Bart Van Assche's message of "Tue, 28 Mar 2017 18:50:01 +0000") Bart Van Assche <Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> writes: Hi Bart, > A quote from SBC: "An OPTIMAL UNMAP GRANULARITY field set to a > non-zero value indicates the optimal granularity in logical blocks for > unmap requests (e.g., an UNMAP command or a WRITE SAME (16) command > with the UNMAP bit set to one). An unmap request with a number of > logical blocks that is not a multiple of this value may result in > unmap operations on fewer LBAs than requested." Indeed. Fewer LBAs than requested may be *unmapped*. That does not imply that they are not *written*. > This means that just like the start and end of a discard must be > aligned on a discard_granularity boundary, WRITE SAME commands with > the UNMAP bit set must also respect that granularity. I think this > means that either __blkdev_issue_zeroout() has to be modified such > that it rejects unaligned REQ_OP_WRITE_ZEROES operations or that > blk_bio_write_same_split() has to be modified such that it generates > REQ_OP_WRITEs for the unaligned start and tail. No, that's not correct. SBC states: "a) if the Data-Out Buffer of the WRITE SAME command is the same as the logical block data returned by a read operation from that LBA while in the unmapped state, then: 1) the device server performs the actions described in table 6 [unmap]; and 2) if an unmap operation is not performed in step 1), then the device server shall perform the specified write operation to that LBA;" I.e. With WRITE SAME it is the responsibility of the device server to write any LBAs described by the command that were not successfully unmapped. -- Martin K. Petersen Oracle Linux Engineering
WARNING: multiple messages have this Message-ID (diff)
From: "Martin K. Petersen" <martin.petersen@oracle.com> To: Bart Van Assche <Bart.VanAssche@sandisk.com> Cc: "agk\@redhat.com" <agk@redhat.com>, "lars.ellenberg\@linbit.com" <lars.ellenberg@linbit.com>, "snitzer\@redhat.com" <snitzer@redhat.com>, "hch\@lst.de" <hch@lst.de>, "martin.petersen\@oracle.com" <martin.petersen@oracle.com>, "philipp.reisner\@linbit.com" <philipp.reisner@linbit.com>, "axboe\@kernel.dk" <axboe@kernel.dk>, "shli\@kernel.org" <shli@kernel.org>, "linux-scsi\@vger.kernel.org" <linux-scsi@vger.kernel.org>, "dm-devel\@redhat.com" <dm-devel@redhat.com>, "drbd-dev\@lists.linbit.com" <drbd-dev@lists.linbit.com>, "linux-block\@vger.kernel.org" <linux-block@vger.kernel.org>, "linux-raid\@vger.kernel.org" <linux-raid@vger.kernel.org> Subject: Re: [PATCH 03/23] sd: implement REQ_OP_WRITE_ZEROES Date: Wed, 29 Mar 2017 22:25:33 -0400 [thread overview] Message-ID: <yq1o9wj4i1u.fsf@oracle.com> (raw) In-Reply-To: <1490726988.2573.16.camel@sandisk.com> (Bart Van Assche's message of "Tue, 28 Mar 2017 18:50:01 +0000") Bart Van Assche <Bart.VanAssche@sandisk.com> writes: Hi Bart, > A quote from SBC: "An OPTIMAL UNMAP GRANULARITY field set to a > non-zero value indicates the optimal granularity in logical blocks for > unmap requests (e.g., an UNMAP command or a WRITE SAME (16) command > with the UNMAP bit set to one). An unmap request with a number of > logical blocks that is not a multiple of this value may result in > unmap operations on fewer LBAs than requested." Indeed. Fewer LBAs than requested may be *unmapped*. That does not imply that they are not *written*. > This means that just like the start and end of a discard must be > aligned on a discard_granularity boundary, WRITE SAME commands with > the UNMAP bit set must also respect that granularity. I think this > means that either __blkdev_issue_zeroout() has to be modified such > that it rejects unaligned REQ_OP_WRITE_ZEROES operations or that > blk_bio_write_same_split() has to be modified such that it generates > REQ_OP_WRITEs for the unaligned start and tail. No, that's not correct. SBC states: "a) if the Data-Out Buffer of the WRITE SAME command is the same as the logical block data returned by a read operation from that LBA while in the unmapped state, then: 1) the device server performs the actions described in table 6 [unmap]; and 2) if an unmap operation is not performed in step 1), then the device server shall perform the specified write operation to that LBA;" I.e. With WRITE SAME it is the responsibility of the device server to write any LBAs described by the command that were not successfully unmapped. -- Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2017-03-30 2:25 UTC|newest] Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-23 14:33 RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload Christoph Hellwig 2017-03-23 14:33 ` [PATCH 01/23] block: renumber REQ_OP_WRITE_ZEROES Christoph Hellwig 2017-03-28 16:12 ` Bart Van Assche 2017-03-28 16:12 ` Bart Van Assche [not found] ` <1490717553.2573.4.camel-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> 2017-03-30 8:53 ` hch-jcswGhMUV9g 2017-03-30 8:53 ` hch 2017-03-23 14:33 ` [PATCH 02/23] block: implement splitting of REQ_OP_WRITE_ZEROES bios Christoph Hellwig 2017-03-23 14:33 ` [PATCH 03/23] sd: implement REQ_OP_WRITE_ZEROES Christoph Hellwig 2017-03-28 18:50 ` Bart Van Assche 2017-03-28 18:50 ` Bart Van Assche [not found] ` <1490726988.2573.16.camel-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> 2017-03-28 19:33 ` Mike Snitzer 2017-03-28 19:33 ` Mike Snitzer 2017-03-30 2:25 ` Martin K. Petersen [this message] 2017-03-30 2:25 ` Martin K. Petersen 2017-03-29 14:51 ` Paolo Bonzini 2017-03-29 16:28 ` Bart Van Assche 2017-03-29 16:28 ` Bart Van Assche 2017-03-29 16:53 ` Paolo Bonzini 2017-03-29 16:53 ` Paolo Bonzini 2017-03-23 14:33 ` [PATCH 04/23] md: support REQ_OP_WRITE_ZEROES Christoph Hellwig 2017-03-23 14:33 ` [PATCH 05/23] dm: " Christoph Hellwig 2017-03-23 14:33 ` [PATCH 06/23] dm-kcopyd: switch to use REQ_OP_WRITE_ZEROES Christoph Hellwig 2017-03-23 14:55 ` Mike Snitzer 2017-03-23 14:56 ` Christoph Hellwig 2017-03-23 15:10 ` Mike Snitzer 2017-03-27 9:12 ` Christoph Hellwig 2017-03-27 9:12 ` Christoph Hellwig 2017-03-23 14:33 ` [PATCH 07/23] block: stop using blkdev_issue_write_same for zeroing Christoph Hellwig 2017-03-23 14:33 ` [PATCH 08/23] block: add a flags argument to (__)blkdev_issue_zeroout Christoph Hellwig 2017-03-23 14:33 ` [PATCH 09/23] block: add a REQ_UNMAP flag for REQ_OP_WRITE_ZEROES Christoph Hellwig 2017-03-23 14:33 ` [PATCH 10/23] block: add a new BLKDEV_ZERO_NOFALLBACK flag Christoph Hellwig 2017-03-23 14:33 ` [PATCH 11/23] block_dev: use blkdev_issue_zerout for hole punches Christoph Hellwig 2017-03-28 16:50 ` Bart Van Assche 2017-03-28 16:50 ` Bart Van Assche [not found] ` <1490719834.2573.9.camel-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> 2017-03-30 8:59 ` hch-jcswGhMUV9g 2017-03-30 8:59 ` hch 2017-03-23 14:33 ` [PATCH 12/23] sd: handle REQ_UNMAP Christoph Hellwig [not found] ` <20170323143341.31549-13-hch-jcswGhMUV9g@public.gmane.org> 2017-03-28 16:48 ` Bart Van Assche 2017-03-28 16:48 ` Bart Van Assche 2017-03-29 14:57 ` Paolo Bonzini [not found] ` <1490719722.2573.8.camel-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org> 2017-03-30 9:02 ` hch-jcswGhMUV9g 2017-03-30 9:02 ` hch [not found] ` <20170330090201.GD12015-jcswGhMUV9g@public.gmane.org> 2017-03-30 15:28 ` Martin K. Petersen 2017-03-30 15:28 ` Martin K. Petersen 2017-03-30 17:30 ` hch 2017-03-30 17:30 ` hch [not found] ` <20170330173020.GB24229-jcswGhMUV9g@public.gmane.org> 2017-03-31 2:19 ` Martin K. Petersen 2017-03-31 2:19 ` Martin K. Petersen [not found] ` <yq17f36yypg.fsf-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> 2017-03-31 7:18 ` hch-jcswGhMUV9g 2017-03-31 7:18 ` hch 2017-03-23 14:33 ` [PATCH 13/23] nvme: implement REQ_OP_WRITE_ZEROES Christoph Hellwig 2017-03-23 14:33 ` [PATCH 14/23] zram: " Christoph Hellwig 2017-03-23 14:33 ` [PATCH 15/23] loop: " Christoph Hellwig 2017-03-23 14:33 ` [PATCH 16/23] brd: remove discard support Christoph Hellwig 2017-03-23 14:33 ` [PATCH 17/23] rbd: remove the discard_zeroes_data flag Christoph Hellwig 2017-03-23 14:33 ` [PATCH 18/23] rsxx: " Christoph Hellwig 2017-03-23 14:33 ` [PATCH 19/23] mmc: " Christoph Hellwig 2017-03-23 14:33 ` [PATCH 20/23] block: stop using discards for zeroing Christoph Hellwig 2017-03-23 14:33 ` [PATCH 21/23] drbd: make intelligent use of blkdev_issue_zeroout Christoph Hellwig 2017-03-23 14:33 ` [PATCH 22/23] drbd: implement REQ_OP_WRITE_ZEROES Christoph Hellwig [not found] ` <20170323143341.31549-23-hch-jcswGhMUV9g@public.gmane.org> 2017-03-30 10:06 ` Lars Ellenberg 2017-03-30 10:06 ` Lars Ellenberg 2017-03-30 11:44 ` Christoph Hellwig 2017-03-30 12:50 ` [Drbd-dev] " Lars Ellenberg [not found] ` <20170330114408.GA15777-jcswGhMUV9g@public.gmane.org> 2017-03-30 13:49 ` Mike Snitzer 2017-03-30 13:49 ` Mike Snitzer [not found] ` <20170330134957.GA508-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2017-03-30 15:20 ` Martin K. Petersen 2017-03-30 15:20 ` Martin K. Petersen 2017-03-30 23:15 ` Mike Snitzer [not found] ` <20170330231550.GA3102-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2017-03-31 2:34 ` Martin K. Petersen 2017-03-31 2:34 ` Martin K. Petersen 2017-03-31 7:17 ` Christoph Hellwig 2017-03-23 14:33 ` [PATCH 23/23] block: remove the discard_zeroes_data flag Christoph Hellwig 2017-03-28 17:00 ` Bart Van Assche 2017-03-28 17:00 ` Bart Van Assche 2017-03-29 14:52 ` Paolo Bonzini 2017-03-30 9:06 ` hch [not found] ` <20170330090655.GF12015-jcswGhMUV9g@public.gmane.org> 2017-03-30 15:29 ` Martin K. Petersen 2017-03-30 15:29 ` Martin K. Petersen 2017-03-30 17:29 ` hch [not found] ` <20170323143341.31549-1-hch-jcswGhMUV9g@public.gmane.org> 2017-03-23 15:54 ` RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload Lars Ellenberg 2017-03-23 15:54 ` Lars Ellenberg 2017-03-23 17:02 ` Mike Snitzer 2017-03-23 17:02 ` Mike Snitzer [not found] ` <20170323170221.GA20854-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2017-03-23 22:53 ` Lars Ellenberg 2017-03-23 22:53 ` Lars Ellenberg 2017-03-29 14:57 ` Paolo Bonzini [not found] ` <20170323155410.GD1138-w1SgEEioFePxa46PmUWvFg@public.gmane.org> 2017-03-27 9:10 ` Christoph Hellwig 2017-03-27 9:10 ` Christoph Hellwig [not found] ` <20170327091056.GB6879-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> 2017-03-27 14:03 ` Mike Snitzer 2017-03-27 14:03 ` Mike Snitzer [not found] ` <20170327140307.GA13020-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2017-03-27 14:57 ` Christoph Hellwig 2017-03-27 14:57 ` Christoph Hellwig 2017-03-27 15:08 ` [Drbd-dev] " Bart Van Assche 2017-03-27 15:08 ` Bart Van Assche 2017-03-30 9:04 ` Christoph Hellwig 2017-03-30 9:04 ` Christoph Hellwig 2017-03-30 15:12 ` Mike Snitzer 2017-03-30 15:22 ` Martin K. Petersen [not found] ` <yq1lgrm3i36.fsf-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> 2017-03-30 15:38 ` Mike Snitzer 2017-03-30 15:38 ` 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=yq1o9wj4i1u.fsf@oracle.com \ --to=martin.petersen-qhclzuegtsvqt0dzr+alfa@public.gmane.org \ --cc=Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org \ --cc=agk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org \ --cc=dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=drbd-dev-cunTk1MwBs8qoQakbn7OcQ@public.gmane.org \ --cc=hch-jcswGhMUV9g@public.gmane.org \ --cc=lars.ellenberg-63ez5xqkn6DQT0dZR+AlfA@public.gmane.org \ --cc=linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-raid-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=philipp.reisner-63ez5xqkn6DQT0dZR+AlfA@public.gmane.org \ --cc=shli-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.