Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757997AbaAJTvJ (ORCPT ); Fri, 10 Jan 2014 14:51:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45501 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751172AbaAJTvG (ORCPT ); Fri, 10 Jan 2014 14:51:06 -0500 Message-ID: <52D04F1A.2000808@redhat.com> Date: Fri, 10 Jan 2014 11:50:50 -0800 From: Andy Grover Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131028 Thunderbird/17.0.10 MIME-Version: 1.0 To: "Nicholas A. Bellinger" CC: Sagi Grimberg , "Nicholas A. Bellinger" , target-devel , linux-scsi , linux-kernel , "Martin K. Petersen" , Christoph Hellwig , Hannes Reinecke , Or Gerlitz Subject: Re: [PATCH 07/14] target/sbc: Add P_TYPE + PROT_EN bits to READ_CAPACITY_16 References: <1389212157-14540-1-git-send-email-nab@daterainc.com> <1389212157-14540-8-git-send-email-nab@daterainc.com> <52CE78EB.60108@mellanox.com> <1389334891.5567.373.camel@haakon3.risingtidesystems.com> In-Reply-To: <1389334891.5567.373.camel@haakon3.risingtidesystems.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/09/2014 10:21 PM, Nicholas A. Bellinger wrote: >> What about FORMAT_UNIT emulation? > > Would certainly be useful to have.. > >> The backstore protection configuration is done at the target side via >> configfs/targetcli, if you publish DIF support in >> INQUERY_EVPD/READ_CAPACITY you need to accept protection information format? > > Mmmm, these two bits bits are following what scsi_debug is currently > exposing minus FORMAT_UNIT support..? > > MKP..? Yes, don't you need FORMAT UNIT because protection information is going to mean the pi-enabled lun will need to report less blocks? The ramdisk backstore changes in this series allocate extra space for PI info, but my understanding was that especially for emulation with block and fileio backstores, everything needs to go in the same amount of space. Furthermore, if we want PI info stored along with the blocks, then block and fileio backstore formats are no longer going to be 1:1 -- requiring offset calculations, non-aligned read-modify-write, and all that unpleasantness to be handled? I've looked at the patchset and the code looks good to me, so I guess I'm trying to understand the scope of future work needed on the backstore side for this support to be functional. Regards -- Andy -- 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/