On Mon, 7 Dec 2020 at 00:05, Hannes Reinecke <hare@xxxxxxx> wrote: > > On 12/6/20 3:14 PM, Tom Yan wrote: > > On Sun, 6 Dec 2020 at 22:05, Hannes Reinecke <hare@xxxxxxx> wrote: > >> > >> On 12/6/20 2:32 PM, Tom Yan wrote: > >>> Why? Did you miss that it is in the condition where > >>> __blkdev_issue_zero_pages() is called (i.e. it's not WRITE SAME but > >>> WRITE). From what I gathered REQ_PREFLUSH triggers a write back cache > >>> (that is on the device; not sure about dirty pages) flush, wouldn't it > >>> be a right thing to do after we performed a series of WRITE (which is > >>> more or less purposed to get a drive wiped clean). > >>> > >> > >> But what makes 'zero_pages' special as compared to, say, WRITE_SAME? > >> One could use WRITE SAME with '0' content, arriving at pretty much the > >> same content than usine zeroout without unmapping. And neither of them > >> worries about cache flushing. > >> Nor should they, IMO. > > > > Because we are writing actual pages (just that they are zero and > > "shared memory" in the system) to the device, instead of triggering a > > special command (with a specific parameter)? > > > > But these pages are ephemeral, and never visible to the user. What do you mean by the "user"? What I meant was, since it's no different than "normal" write operation, the zero pages will go to the volatile write cache of the device. > > >> > >> These are 'native' block layer calls, providing abstract accesses to > >> hardware functionality. If an application wants to use them, it would be > >> the task of the application to insert a 'flush' if it deems neccessary. > >> (There _is_ blkdev_issue_flush(), after all). > > > > Well my argument would be the call has the purpose of "wiping" so it > > should try to "atomically" guarantee that the wiping is synced. It's > > like a complement to REQ_SYNC in the final submit_bio_wait(). > > > That's an assumption. > > It would be valid if blkdev_issue_zeroout() would only allow to wipe the > entire disk. As it stands, it doesn't, and so we shouldn't presume what > users might want to do with it. Whether it's an entire disk doesn't matter. It still stands when it's only a certain range of blocks. > > Cheers, > > Hannes > -- > Dr. Hannes Reinecke Kernel Storage Architect > hare@xxxxxxx +49 911 74053 688 > SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg > HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
