Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030467AbaGPTVU (ORCPT ); Wed, 16 Jul 2014 15:21:20 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:23118 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932081AbaGPTVL (ORCPT ); Wed, 16 Jul 2014 15:21:11 -0400 To: "Elliott\, Robert \(Server Storage\)" Cc: James Bottomley , "martin.petersen\@oracle.com" , "linux-kernel\@vger.kernel.org" , "hch\@infradead.org" , "devel\@linuxdriverproject.org" , "apw\@canonical.com" , "kys\@microsoft.com" , "stable\@vger.kernel.org" , "linux-scsi\@vger.kernel.org" , "ohering\@suse.com" , "jasowang\@redhat.com" Subject: Re: [PATCH 4/8] Drivers: scsi: storvsc: Filter WRITE_SAME_16 From: "Martin K. Petersen" Organization: Oracle Corporation References: <20140709084300.GD6012@infradead.org> <1404935792.2184.5.camel@dabdike.int.hansenpartnership.com> <2f3ae589e6f149acbe4c5dd79f905971@BY2PR03MB299.namprd03.prod.outlook.com> <1404944843.2184.8.camel@dabdike.int.hansenpartnership.com> <20140711063216.GA20660@infradead.org> <328b7a6174ef4dd8a54a7db5ac959834@BY2PR03MB299.namprd03.prod.outlook.com> <20140716110111.GA7382@infradead.org> <20140716173827.GB20528@infradead.org> <1405533734.3165.12.camel@dabdike.int.hansenpartnership.com> <94D0CD8314A33A4D9D801C0FE68B402958BA721F@G9W0745.americas.hpqcorp.net> Date: Wed, 16 Jul 2014 15:20:00 -0400 In-Reply-To: <94D0CD8314A33A4D9D801C0FE68B402958BA721F@G9W0745.americas.hpqcorp.net> (Robert Elliott's message of "Wed, 16 Jul 2014 18:43:43 +0000") Message-ID: User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Source-IP: acsinet22.oracle.com [141.146.126.238] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>>>> "Rob" == Elliott, Robert (Server Storage) writes: Rob> WRITE SAME with the UNMAP bit set to one (and a few other Rob> conditions) guarantees that the data is zeroed out, while the UNMAP Rob> command is just a hint. They're not fully interchangeable. Which Rob> semantics are implied by REQ_DISCARD and these functions? Voluntary deprovisioning of a block range. Rob> One benefit of UNMAP is that UNMAP supports a list of discontiguous Rob> LBA ranges, whereas WRITE SAME just supports one LBA range. Rob> sd_setup_discard_cmnd is not taking advantage of this feature, Rob> though. The block layer can only describe one contiguous block range in a request. My copy offload patches introduces the bi_special field that allows us to attach additional information to an I/O. I have experimented with doing that for discards to overcome the suck of DSM TRIM. Splitting and merging requests in MD/DM gets much more cumbersome, though. Rob> Ideally, the block layer would merge multiple discards into one Rob> UNMAP command if they're stuck on the request queue for a while, Rob> like it merges adjacent reads and writes. We support merging contiguous smaller discard requests. We did discuss having a (separate) I/O scheduler to coalesce discontiguous discard requests. However, the attempts at this turned out to be pretty hideous. It also wasn't evident that it was worth the hassle. While UNMAP allows us to express large regions, DSM TRIM on the SATA side is limited to 32 MB per range. So in many cases we end up maxing out the payload capacity even with a single contiguous range. We expect LBP SCSI devices to queue commands. Being able to express multiple ranges in one shot is less critical in that case. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/