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)? > > 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(). > > 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
