From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757524AbZEDOlF (ORCPT ); Mon, 4 May 2009 10:41:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757482AbZEDOkl (ORCPT ); Mon, 4 May 2009 10:40:41 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:32901 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757475AbZEDOkj (ORCPT ); Mon, 4 May 2009 10:40:39 -0400 Subject: Re: New TRIM/UNMAP tree published (2009-05-02) From: James Bottomley To: dgilbert@interlog.com Cc: Jeff Garzik , Matthew Wilcox , Jens Axboe , Boaz Harrosh , Hugh Dickins , Matthew Wilcox , linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, Bartlomiej Zolnierkiewicz , Mark Lord In-Reply-To: <49FEF5C5.6010404@interlog.com> References: <1238683047-13588-1-git-send-email-willy@linux.intel.com> <49D8A3D7.5070507@panasas.com> <20090503061150.GF10704@linux.intel.com> <20090503071619.GP8822@parisc-linux.org> <20090503144847.GR8822@parisc-linux.org> <49FDB21B.3080301@panasas.com> <20090503154216.GU8822@parisc-linux.org> <49FDC786.6070309@panasas.com> <49FDE3BB.505@garzik.org> <49FDE50A.4060503@garzik.org> <1241377472.5596.88.camel@mulgrave.int.hansenpartnership.com> <49FDEE64.5090302@garzik.org> <1241379476.5596.92.camel@mulgrave.int.hansenpartnership.com> <49FEF5C5.6010404@interlog.com> Content-Type: text/plain Date: Mon, 04 May 2009 14:40:37 +0000 Message-Id: <1241448038.3315.19.camel@mulgrave.int.hansenpartnership.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2009-05-04 at 16:03 +0200, Douglas Gilbert wrote: > James Bottomley wrote: > > On Sun, 2009-05-03 at 15:20 -0400, Jeff Garzik wrote: > >> Is WRITE SAME associated with this current DISCARD work, or is that just > >> a similar example? I'm unfamiliar with its issues... > > > > It's an adjunct body of work. T10 apparently ratified both UNMAP and > > the WRITE SAME extensions. What WRITE SAME does is write the same data > > block to multiple contiguous locations as specified in the CDB. What > > the thin provisioning update did for it is allow you to specify a flag > > saying I want these sectors unmapped. The perceived benefit of WRITE > > SAME is that you specify (with the write same data ... presumably all > > zeros) what an unmapped sector will return if it's ever read from again, > > which was a big argument in the UNMAP case. > > James, > Your presumption is correct. For the UNMAP bit to be honoured > in the SCSI WRITE SAME command, the user data part of the > data-out buffer needs to be all zeros, and, if present, > the protection data part of the data-out buffer needs > to be all 0xff_s (i.e. 8 bytes of 0xff). Otherwise the > UNMAP bit in WRITE SAME command is ignored and it does a > "normal" WRITE SAME. > > My $0.02's worth was a suggestion to report an error if the > UNMAP bit was given to WRITE SAME and the data-out > buffer did not comply with the above pattern. Alternatively > the data-out buffer could just be ignored. The author > of the WRITE SAME "unmap" facility duly noted my observations > and rejected them :-) The wording in sbc3r18.pdf for WRITE SAME > is contorted so there will be changes. And t10 is still > having teleconferences about thin provisioning so there may be > non-trivial changes in the near future. Actually, I'd just like something far more basic: forcing a thin provisioned array to support all of the three possible mechanisms. It's going to be a real mess trying to work out for any given array do you support UNMAP or WRITE SAME(16) or WRITE SAME(32)? We can only do this currently by trying the commands ... then we have to have support for all three built into sd just in case ... and we get precisely the same functionality in each case ... James