From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 3 Feb 2017 17:12:39 +0100 From: Christoph Hellwig To: Jens Axboe Cc: Junichi Nomura , "linux-block@vger.kernel.org" , linux-scsi , Christoph Hellwig , Chaitanya Kulkarni , "Martin K. Petersen" Subject: Re: [REGRESSION v4.10-rc1] blkdev_issue_zeroout() returns -EREMOTEIO on the first call for SCSI device that doesn't support WRITE SAME Message-ID: <20170203161239.GA3880@lst.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: List-ID: On Fri, Feb 03, 2017 at 08:21:31AM -0700, Jens Axboe wrote: > > Error 121 (EREMOTEIO) was returned from blkdev_issue_zeroout(). > > That came from sd driver because WRITE SAME was sent to the device > > which didn't support it. > > > > The problem was introduced by commit e73c23ff736e ("block: add async > > variant of blkdev_issue_zeroout"). Before the commit, blkdev_issue_zeroout > > fell back to normal zero writing when WRITE SAME failed and it seems > > sd driver's heuristics depends on that behaviour. > > CC Christoph and Chaitanya. And adding Martin as the sd.c Write Same code is his. I suspect we'll have to restore the old way this works for 4.10 as it's too late in the cycle, but that whole idea of trying Write Same first and just disabling it if it doesn't work is a receipe for desaster - it kinda works for a synchronous blkdev_issue_zeroout, but if we want to be able to submit it asynchronously it's getting too hairy to handle. I think we should fix sd.c to only send WRITE SAME if either of the variants are explicitly listed as supported through REPORT SUPPORTED OPERATION CODES, or maybe through a whitelist if there are important enough devices.