From jforte@sac.sfbay.sun.com Tue Apr 1 17:11:12 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m320BB05006640 for ; Tue, 1 Apr 2008 17:11:12 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m320B19F016155; Wed, 2 Apr 2008 01:11:11 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYO005038IKLD00@nwk-avmta-2.sfbay.sun.com>; Tue, 01 Apr 2008 17:11:08 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYO0025M8IJDQ50@nwk-avmta-2.sfbay.sun.com>; Tue, 01 Apr 2008 17:11:08 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m320B75E005189; Tue, 01 Apr 2008 17:11:07 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m320B6sQ006635; Tue, 01 Apr 2008 17:11:06 -0700 (PDT) Received: (from jforte@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m320B6fE006631; Tue, 01 Apr 2008 17:11:06 -0700 (PDT) Date: Tue, 01 Apr 2008 17:11:06 -0700 (PDT) From: John Forte Subject: SCSI Block Disk Provider for COMSTAR [PSARC/2008/235 FastTrack] To: PSARC-ext@sun.com Cc: sumit.gupta@sun.com Message-id: <200804020011.m320B6fE006631@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 8954 I am sponsoring this fasttrack for Sumit Gupta. Requested binding is Patch, timeout is 04/09/2008 - John Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: SCSI Block Disk Provider for COMSTAR 1.2. Name of Document Author/Supplier: Author: Sumit Gupta 1.3 Date of This Document: 01 April, 2008 4. Technical Description SCSI Block Disk Provider for COMSTAR 1. Summary This command (sbdadm) and associated driver (sbd) will provide SCSI block disk device support for COMSTAR (PSARC/2007/523). The command sbdadm(1M) will provide support for creating logical units utilizing any file or raw block device as the backing store. Logical units created with sbdadm will be available to the COMSTAR framework and can be further managed and provisioned to storage clients in the network using stmfadm(1M). Logical units created with sbdadm(1M) are persistent across reboots. 2. Documentation NAME sbdadm - SCSI Block Disk Command Line Interface SYNOPSIS sbdadm create-lu [-s, --size ] sbdadm delete-lu sbdadm import-lu sbdadm list-lu sbdadm modify-lu [-s, --size ] | DESCRIPTION The sbdadm command provides the ability to create SCSI disk type Logical Units and register them with the SCSI Target Mode Framework described by stmf(7D) so that they can be exposed outside of the Solaris host to other initiators on the storage network. The SCSI Logical Unit thus created uses the specified file as its backing store to store the logical unit data. The size of the Logical Unit is derived from the size of the file minus 64K to store the control information for the Logical Unit. The size of the Logical unit can also be specified by the command line option in which case it is possible to create Logical Units without initially occupying any physical storage. The maximum supported size for a Logical Unit is 8 Exabytes. filename Name of an existing file or a fully qualified path to a raw block device. lu_name The 32-byte hexadecimal representation of the logical unit. This is available in the output of "sbdadm create-lu" or from "sbdadm list-lu". This 32-byte hexadecimal representation will also be available using the stmfadm(1M) command. SUBCOMMANDS sbdadm -? sbdadm create-lu [-s, --size ] Create a logical unit that can be registered with stmf(7D). -s, --size is an integer value which can be followed by one of the following letters to indicate : k kilobyte m megabyte g gigabyte t terabyte p petabyte e exabyte If this option is not specified, defaults to the size of . The size specified may exceed the size of the file or device. sbdadm delete-lu Delete an existing logical unit that was created using "sbdadm create". This removes the logical unit from stmf. Any existing data on the logical unit remains intact. sbdadm import-lu Imports and loads a logical unit into stmf that was previously created using "sbdadm create" and since deleted from stmf using "sbdadm delete". On success, the logical unit is again made available to stmf. filename is the filename that was used in the sbdadm create-lu command for this logical unit. sbdadm list-lu List all logical units that were created using the "sbdadm create" command. sbdadm modify-lu [-s, --size ] | Modifies attributes of an existing logical unit created using the "sbdadm create" command. -s, --size lun_size is an integer value followed by one of the following letters to indicate : k kilobyte m megabyte g gigabyte t terabyte p petabyte e exabyte When this option is specified, the existing size of the logical unit is modified to the new size. The size specified may exceed the size of the file or device. EXAMPLES Example 1 Creating a logical unit specifying a size. The following commands create a file and then a logical unit using the -s option to specify a size: # touch /export/lun/0 # sbdadm create-lu -s 10g /export/lun/0 Created the following LU: GUID DATA SIZE SOURCE ------------------------------------ ---------------- ---------------- 6000ae401d000000000047f2a6320001 10737418240 /export/lun/0 Example 2 Creating a logical unit using the existing size of the backing store. The following command creates a logical unit using the existing size of the backing store: # sbdadm create-lu /dev/rdsk/c1t1d0s0 Created the following LU: GUID DATA SIZE SOURCE ------------------------------------ ---------------- ---------------- 6000ae4000144f21d92c47b0de300032 134283264 /dev/rdsk/c1t1d0s0 Example 3 Listing logical units The following command will list all logical units that have been registered with stmf(7D): # sbdadm list-lu Found 2 LU(s) GUID DATA SIZE SOURCE ------------------------------------ ----------------- ---------------- 6000ae401d000000000047f2a6320001 10737418240 /export/lun/0 6000ae4000144f21d92c47b0de300032 134283264 /dev/rdsk/c1t1d0s0 Example 4 Exporting a logical unit The following commands create and then export a logical unit using stmfadm(1M): # sbdadm create-lu -s 10g /export/lun/0 Created the following LU: GUID DATA SIZE SOURCE ------------------------------------ ---------------- ---------------- 6000ae401d000000000047f2a6320001 10737418240 /export/lun/0 # stmfadm add-view 6000ae401d000000000047f2a6320001 Example 5 Deleting a logical unit and view entries The following command will delete the logical unit as well as any view entries that were created using stmfadm(1M): # sbdadm delete-lu 6000ae401d000000000047f2a6320001 Example 6 Deleting a logical unit and keeping view entries The following command will delete the logical unit but keep any view entries that were created using stmfadm(1M): # sbdadm delete-lu -k 6000ae401d000000000047f2a6320001 EXIT STATUS 0 Operation was successful >0 An error occurred. ATTRIBUTES See attributes(5) for descriptions of the following attributes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Availability | SUNWkdcu | |_____________________________|_____________________________| | Interface Stability | See below | |_____________________________|_____________________________| The command line interface (CLI) is Uncommitted. The CLI output is Not an Interface. SEE ALSO stmfadm(1M), stmf(7D) 3. Interface table: Interfaces Imported -------------+--------------------+------------------------- Interface | Classification | Comments -------------+--------------------+------------------------- kernel/fs | Consolidation | vn_open | Private | vn_rdwr | | VOP_FSYNC | | VOP_GETATTR | | VOP_PATHCONF | | VOP_CLOSE | | | | contract-sbd in case directory | | stmf | Committed | Framework functions for LU | | providers and port providers. | | PSARC 2007/523 | | libstmf | Committed | user library interfaces for | | PSARC 2007/523 Interfaces Exported -------------+--------------------+------------------------- Interface | Classification | Comments -------------+--------------------+------------------------- sbdadm | Committed | CLI command and options sbdadm output| Not an interface | 4. References PSARC 2007/523 COMSTAR: Common Multiprotocol SCSI Target 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: NWSC 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Andrew.Gabriel@sun.com Wed Apr 2 08:52:39 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m32Fqdji000970 for ; Wed, 2 Apr 2008 08:52:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m32FqaDW029455 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Apr 2008 09:52:39 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYP00G1DG3PSC00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Apr 2008 09:52:37 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYP008J2G3O9670@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Apr 2008 09:52:37 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m32FqaPx006265 for ; Wed, 02 Apr 2008 15:52:36 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYP00501FNDB300@fe-emea-10.sun.com> (original mail from Andrew.Gabriel@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Apr 2008 16:52:36 +0100 (BST) Received: from [129.156.86.102] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYP004S8G3K5F50@fe-emea-10.sun.com>; Wed, 02 Apr 2008 16:52:33 +0100 (BST) Date: Wed, 02 Apr 2008 16:52:32 +0100 From: Andrew Gabriel Subject: Re: SCSI Block Disk Provider for COMSTAR [PSARC/2008/235 FastTrack] In-reply-to: <200804020011.m320B6fE006631@sac.sfbay.sun.com> Sender: Andrew.Gabriel@sun.com To: John Forte Cc: PSARC-ext@sun.com, Sumit.Gupta@sun.com Reply-to: Andrew.Gabriel@sun.com Message-id: <47F3ABC0.4080205@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804020011.m320B6fE006631@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 4377 John Forte wrote: > I am sponsoring this fasttrack for Sumit Gupta. Requested binding is Patch, > timeout is 04/09/2008 > > - John > > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > SCSI Block Disk Provider for COMSTAR > 1.2. Name of Document Author/Supplier: > Author: Sumit Gupta > 1.3 Date of This Document: > 01 April, 2008 > 4. Technical Description > SCSI Block Disk Provider for COMSTAR > > > 1. Summary > > This command (sbdadm) and associated driver (sbd) will provide SCSI block disk > device support for COMSTAR (PSARC/2007/523). The command sbdadm(1M) will > provide support for creating logical units utilizing any file or raw block > device as the backing store. Logical units created with sbdadm will be > available to the COMSTAR framework and can be further managed and provisioned > to storage clients in the network using stmfadm(1M). Logical units created > with sbdadm(1M) are persistent across reboots. > > 2. Documentation > > NAME > sbdadm - SCSI Block Disk Command Line Interface > > SYNOPSIS > sbdadm create-lu [-s, --size ] > sbdadm delete-lu > sbdadm import-lu > sbdadm list-lu > sbdadm modify-lu [-s, --size ] | > > > DESCRIPTION > > The sbdadm command provides the ability to create SCSI disk type > Logical Units and register them with the SCSI Target Mode Framework > described by stmf(7D) so that they can be exposed outside of the > Solaris host to other initiators on the storage network. > > The SCSI Logical Unit thus created uses the specified file as its > backing store to store the logical unit data. The size of the > Logical Unit is derived from the size of the file minus 64K > to store the control information for the Logical Unit. The size > of the Logical unit can also be specified by the command line > option in which case it is possible to create Logical Units > without initially occupying any physical storage. The maximum > supported size for a Logical Unit is 8 Exabytes. > > filename Name of an existing file or a fully qualified path to a > raw block device. > > lu_name The 32-byte hexadecimal representation of the logical > unit. This is available in the output of "sbdadm create-lu" > or from "sbdadm list-lu". This 32-byte hexadecimal > representation will also be available using the stmfadm(1M) > command. > > SUBCOMMANDS > sbdadm -? > > sbdadm create-lu [-s, --size ] > > Create a logical unit that can be registered with stmf(7D). > > -s, --size > > is an integer value which can be followed by > one of the following letters to indicate : > k kilobyte > m megabyte > g gigabyte > t terabyte > p petabyte > e exabyte > > If this option is not specified, defaults to > the size of . > > The size specified may exceed the size of the file or > device. > I'm just wondering if there's a piece of potentially useful functionality which is almost, but not quite here, and might be worthy of consideration? I'm thinking of a case where you have taken a copy of an existing disk which is to be retired in the form of a whole disk image (e.g. using dd(1)) into a file, and you want to reprovision this disk image file using iSCSI. It looks to me like I can't quite do that with the existing command set, i.e. bring in an existing raw disk image (not one created with the proposed create-lu subcommand). I could see this as a potentially useful feature during a server consolidation program, to be able to grab images of disks from the individual servers which are to be decommissioned and reprovision these file images from an iSCSI target server. This should go with a reverse function to export the raw disk image (i.e. strip off the 64k control information). If the control information was defined to be at the end of the file/media, in many cases, applications which expect to access disk images could use these files directly too. (Would also make adding and stripping it easy.) This could also be useful to work around the missing disk label support in lofi(7D). -- Andrew Gabriel From glenn.skinner@sun.com Wed Apr 2 09:20:36 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m32GKZMD002627 for ; Wed, 2 Apr 2008 09:20:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m32GKWKb028110; Thu, 3 Apr 2008 00:20:33 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYP00J37HE7TI00@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Apr 2008 09:20:31 -0700 (PDT) Received: from ivrel.sfbay.sun.com ([129.146.74.76]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYP00I3ZHE36270@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Apr 2008 09:20:27 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id m32GKQWi006890; Wed, 02 Apr 2008 09:20:26 -0700 (PDT) Date: Wed, 02 Apr 2008 09:20:26 -0700 (PDT) From: Glenn Skinner Subject: Re: 2008/235 [SCSI Block Disk Provider for COMSTAR] To: PSARC-ext@sun.com, jforte@sac.sfbay.sun.com Cc: sumit.gupta@sun.com Reply-to: Glenn Skinner Message-id: <200804021620.m32GKQWi006890@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: kxeNCxZYMWDALj7fLVC4mg== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 885 Date: Tue, 01 Apr 2008 17:11:06 -0700 (PDT) From: John Forte Subject: SCSI Block Disk Provider for COMSTAR [PSARC/2008/235 FastTrack] ... 1. Summary This command (sbdadm) and associated driver (sbd) will provide SCSI block disk device support for COMSTAR (PSARC/2007/523). The command sbdadm(1M) will provide support for creating logical units utilizing any file or raw block device as the backing store. Logical units created with sbdadm will be available to the COMSTAR framework and can be further managed and provisioned to storage clients in the network using stmfadm(1M). Logical units created with sbdadm(1M) are persistent across reboots. How is persistence accomplished? That is, where and how is the state stored? I didn't see any mention of that in the interface table. -- Glenn From John.Forte@sun.com Wed Apr 2 09:56:08 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m32Gu8U8005275 for ; Wed, 2 Apr 2008 09:56:08 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m32Gu406054532; Wed, 2 Apr 2008 10:56:07 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYP00L0TJ1G5M00@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Apr 2008 09:56:05 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYP00IPNJ1C5YA0@nwk-avmta-2.sfbay.sun.com>; Wed, 02 Apr 2008 09:56:01 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m32Gu082026545; Wed, 02 Apr 2008 16:56:00 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYP00801IX34L00@mail-amer.sun.com> (original mail from John.Forte@Sun.COM); Wed, 02 Apr 2008 10:56:00 -0600 (MDT) Received: from john-fortes-macbook-pro.local ([71.139.45.159]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYP00DY9J0XV440@mail-amer.sun.com>; Wed, 02 Apr 2008 10:55:56 -0600 (MDT) Date: Wed, 02 Apr 2008 09:51:29 -0700 From: John Forte Subject: Re: 2008/235 [SCSI Block Disk Provider for COMSTAR] In-reply-to: <200804021620.m32GKQWi006890@ivrel.sfbay.sun.com> Sender: John.Forte@sun.com To: Glenn Skinner Cc: PSARC-ext@sun.com, jforte@sac.sfbay.sun.com, Sumit.Gupta@sun.com Message-id: <47F3B991.7020307@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804021620.m32GKQWi006890@ivrel.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 1145 Glenn Skinner wrote: > Date: Tue, 01 Apr 2008 17:11:06 -0700 (PDT) > From: John Forte > Subject: SCSI Block Disk Provider for COMSTAR [PSARC/2008/235 > FastTrack] > > ... > 1. Summary > > This command (sbdadm) and associated driver (sbd) will provide > SCSI block disk device support for COMSTAR (PSARC/2007/523). The > command sbdadm(1M) will provide support for creating logical units > utilizing any file or raw block device as the backing store. > Logical units created with sbdadm will be available to the COMSTAR > framework and can be further managed and provisioned to storage > clients in the network using stmfadm(1M). Logical units created > with sbdadm(1M) are persistent across reboots. > > How is persistence accomplished? That is, where and how is the state > stored? I didn't see any mention of that in the interface table. > > The specific library interfaces are not listed in the interface table but the support is provided by libstmf. The interfaces that provide the support are: stmfGetProviderData() stmfSetProviderData() - John From Sumit.Gupta@Sun.COM Wed Apr 2 10:44:34 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m32HiYhl011693 for ; Wed, 2 Apr 2008 10:44:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m32HiWr9015102 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Apr 2008 10:44:33 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYP00M0VLA9MP00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Apr 2008 10:44:33 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYP00ID8LA65WE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Apr 2008 10:44:30 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m32HiULI018370 for ; Wed, 02 Apr 2008 10:44:30 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYP00301KID3500@fe-sfbay-09.sun.com> (original mail from Sumit.Gupta@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Apr 2008 10:44:30 -0700 (PDT) Received: from [192.168.0.2] ([129.150.21.210]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYP000PWL9YWRA0@fe-sfbay-09.sun.com>; Wed, 02 Apr 2008 10:44:22 -0700 (PDT) Date: Wed, 02 Apr 2008 10:44:20 -0700 From: Sumit Gupta Subject: Re: SCSI Block Disk Provider for COMSTAR [PSARC/2008/235 FastTrack] In-reply-to: <47F3ABC0.4080205@Sun.COM> Sender: Sumit.Gupta@Sun.COM To: Andrew.Gabriel@Sun.COM Cc: John Forte , psarc-ext@Sun.COM Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.753) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804020011.m320B6fE006631@sac.sfbay.sun.com> <47F3ABC0.4080205@Sun.COM> Status: RO Content-Length: 5199 On Apr 2, 2008, at 8:52 AM, Andrew Gabriel wrote: > John Forte wrote: >> I am sponsoring this fasttrack for Sumit Gupta. Requested binding >> is Patch, >> timeout is 04/09/2008 >> >> - John >> >> >> Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >> This information is Copyright 2008 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> SCSI Block Disk Provider for COMSTAR >> 1.2. Name of Document Author/Supplier: >> Author: Sumit Gupta >> 1.3 Date of This Document: >> 01 April, 2008 >> 4. Technical Description >> SCSI Block Disk Provider for COMSTAR >> >> >> 1. Summary >> >> This command (sbdadm) and associated driver (sbd) will provide >> SCSI block disk >> device support for COMSTAR (PSARC/2007/523). The command sbdadm >> (1M) will >> provide support for creating logical units utilizing any file or >> raw block device as the backing store. Logical units created with >> sbdadm will be >> available to the COMSTAR framework and can be further managed and >> provisioned >> to storage clients in the network using stmfadm(1M). Logical units >> created with sbdadm(1M) are persistent across reboots. >> >> 2. Documentation >> >> NAME >> sbdadm - SCSI Block Disk Command Line Interface >> >> SYNOPSIS >> sbdadm create-lu [-s, --size ] >> sbdadm delete-lu >> sbdadm import-lu >> sbdadm list-lu >> sbdadm modify-lu [-s, --size ] | >> >> >> DESCRIPTION >> >> The sbdadm command provides the ability to create SCSI disk type >> Logical Units and register them with the SCSI Target Mode Framework >> described by stmf(7D) so that they can be exposed outside of the >> Solaris host to other initiators on the storage network. >> >> The SCSI Logical Unit thus created uses the specified file as its >> backing store to store the logical unit data. The size of the >> Logical Unit is derived from the size of the file minus 64K >> to store the control information for the Logical Unit. The size >> of the Logical unit can also be specified by the command line >> option in which case it is possible to create Logical Units >> without initially occupying any physical storage. The maximum >> supported size for a Logical Unit is 8 Exabytes. >> >> filename Name of an existing file or a fully qualified path to a >> raw block device. >> >> lu_name The 32-byte hexadecimal representation of the logical >> unit. This is available in the output of "sbdadm create- >> lu" or from "sbdadm list-lu". This 32-byte >> hexadecimal >> representation will also be available using >> the stmfadm(1M) >> command. >> >> SUBCOMMANDS >> sbdadm -? >> >> sbdadm create-lu [-s, --size ] >> >> Create a logical unit that can be registered with stmf(7D). >> >> -s, --size >> >> is an integer value which can be followed by >> one of the following letters to indicate : >> k kilobyte >> m megabyte >> g gigabyte >> t terabyte >> p petabyte >> e exabyte >> >> If this option is not specified, defaults to >> the size of . >> >> The size specified may exceed the size of the file or >> device. >> > > I'm just wondering if there's a piece of potentially useful > functionality > which is almost, but not quite here, and might be worthy of > consideration? > > I'm thinking of a case where you have taken a copy of an existing disk > which is to be retired in the form of a whole disk image (e.g. > using dd(1)) > into a file, and you want to reprovision this disk image file using > iSCSI. > It looks to me like I can't quite do that with the existing command > set, > i.e. bring in an existing raw disk image (not one created with the > proposed > create-lu subcommand). I could see this as a potentially useful > feature > during a server consolidation program, to be able to grab images of > disks > from the individual servers which are to be decommissioned and > reprovision > these file images from an iSCSI target server. This should go with a > reverse function to export the raw disk image (i.e. strip off the 64k > control information). > > If the control information was defined to be at the end of the file/ > media, > in many cases, applications which expect to access disk images > could use > these files directly too. (Would also make adding and stripping it > easy.) > > This could also be useful to work around the missing disk label > support in > lofi(7D). We have looked into that approach but to support dynamic expansion of LUs, we cannot always write to the end or even read from it. Also there is another case where this disk image support may be required to work with the raw device itself. In which case also we wont be able to add to the end of the raw device. But we are looking into other ways of exporting existing disk images and one option is to use a separate file to store the LU metadata which seem to be generic and something we can add in near future. Thanks Sumit > > -- > Andrew Gabriel From Andrew.Gabriel@sun.com Thu Apr 3 03:24:39 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m33AOcPd009035 for ; Thu, 3 Apr 2008 03:24:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m33AOZuE027614 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 3 Apr 2008 11:24:37 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYQ00H19VL00V00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 Apr 2008 03:24:36 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYQ008ISVKYLGD0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 Apr 2008 03:24:35 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m33AOXwD001688 for ; Thu, 03 Apr 2008 10:24:33 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYQ00E01V4KJ200@fe-emea-10.sun.com> (original mail from Andrew.Gabriel@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 Apr 2008 11:24:33 +0100 (BST) Received: from [129.156.86.113] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYQ001OAVKRWGF0@fe-emea-10.sun.com>; Thu, 03 Apr 2008 11:24:33 +0100 (BST) Date: Thu, 03 Apr 2008 11:24:27 +0100 From: Andrew Gabriel Subject: Re: SCSI Block Disk Provider for COMSTAR [PSARC/2008/235 FastTrack] In-reply-to: Sender: Andrew.Gabriel@sun.com To: Sumit Gupta Cc: John Forte , psarc-ext@sun.com Reply-to: Andrew.Gabriel@sun.com Message-id: <47F4B05B.1000604@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804020011.m320B6fE006631@sac.sfbay.sun.com> <47F3ABC0.4080205@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2324 Sumit Gupta wrote: > > On Apr 2, 2008, at 8:52 AM, Andrew Gabriel wrote: > >> I'm just wondering if there's a piece of potentially useful >> functionality >> which is almost, but not quite here, and might be worthy of >> consideration? >> >> I'm thinking of a case where you have taken a copy of an existing disk >> which is to be retired in the form of a whole disk image (e.g. using >> dd(1)) >> into a file, and you want to reprovision this disk image file using >> iSCSI. >> It looks to me like I can't quite do that with the existing command set, >> i.e. bring in an existing raw disk image (not one created with the >> proposed >> create-lu subcommand). I could see this as a potentially useful feature >> during a server consolidation program, to be able to grab images of >> disks >> from the individual servers which are to be decommissioned and >> reprovision >> these file images from an iSCSI target server. This should go with a >> reverse function to export the raw disk image (i.e. strip off the 64k >> control information). >> >> If the control information was defined to be at the end of the >> file/media, >> in many cases, applications which expect to access disk images could use >> these files directly too. (Would also make adding and stripping it >> easy.) >> >> This could also be useful to work around the missing disk label >> support in >> lofi(7D). > > We have looked into that approach but to support dynamic expansion > of LUs, we cannot always write to the end or even read from it. Also > there is another case where this disk image support may be required to > work with the raw device itself. In which case also we wont be able to > add to the end of the raw device. But we are looking into other ways > of exporting existing disk images and one option is to use a separate > file to store the LU metadata which seem to be generic and something > we can add in near future. A separate file to store the LU metadata would solve these issues. If you are going to be doing that for these reasons, does it make sense to have two different formats for iSCSI disk images, one with the metadata included and one with it separate? I could see this leading to unnecessary confusion and complexity. Why not just go for the separate metadata file case now? -- Andrew Gabriel From Sumit.Gupta@sun.com Thu Apr 3 13:50:49 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m33KomdZ001813 for ; Thu, 3 Apr 2008 13:50:49 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m33KokJX004830 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 4 Apr 2008 04:50:48 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JYR00E0ROKMKH00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 Apr 2008 13:50:46 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JYR0069IOKLC8F0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 Apr 2008 13:50:45 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m33KojSo013704 for ; Thu, 03 Apr 2008 13:50:45 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYR00601OGXK200@fe-sfbay-09.sun.com> (original mail from Sumit.Gupta@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 03 Apr 2008 13:50:45 -0700 (PDT) Received: from [129.146.56.70] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYR007PVOKHH300@fe-sfbay-09.sun.com>; Thu, 03 Apr 2008 13:50:41 -0700 (PDT) Date: Thu, 03 Apr 2008 13:50:37 -0700 From: Sumit Gupta Subject: Re: SCSI Block Disk Provider for COMSTAR [PSARC/2008/235 FastTrack] In-reply-to: <47F4B05B.1000604@Sun.COM> Sender: Sumit.Gupta@sun.com To: Andrew.Gabriel@sun.com Cc: John Forte , psarc-ext@sun.com Message-id: <47F5431D.4080101@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200804020011.m320B6fE006631@sac.sfbay.sun.com> <47F3ABC0.4080205@Sun.COM> <47F4B05B.1000604@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080115) Status: RO Content-Length: 2861 Andrew Gabriel wrote: > Sumit Gupta wrote: >> >> On Apr 2, 2008, at 8:52 AM, Andrew Gabriel wrote: >> >>> I'm just wondering if there's a piece of potentially useful >>> functionality >>> which is almost, but not quite here, and might be worthy of >>> consideration? >>> >>> I'm thinking of a case where you have taken a copy of an existing disk >>> which is to be retired in the form of a whole disk image (e.g. using >>> dd(1)) >>> into a file, and you want to reprovision this disk image file using >>> iSCSI. >>> It looks to me like I can't quite do that with the existing command >>> set, >>> i.e. bring in an existing raw disk image (not one created with the >>> proposed >>> create-lu subcommand). I could see this as a potentially useful feature >>> during a server consolidation program, to be able to grab images of >>> disks >>> from the individual servers which are to be decommissioned and >>> reprovision >>> these file images from an iSCSI target server. This should go with a >>> reverse function to export the raw disk image (i.e. strip off the 64k >>> control information). >>> >>> If the control information was defined to be at the end of the >>> file/media, >>> in many cases, applications which expect to access disk images could >>> use >>> these files directly too. (Would also make adding and stripping it >>> easy.) >>> >>> This could also be useful to work around the missing disk label >>> support in >>> lofi(7D). >> >> We have looked into that approach but to support dynamic >> expansion of LUs, we cannot always write to the end or even read from >> it. Also there is another case where this disk image support may be >> required to work with the raw device itself. In which case also we >> wont be able to add to the end of the raw device. But we are looking >> into other ways of exporting existing disk images and one option is >> to use a separate file to store the LU metadata which seem to be >> generic and something we can add in near future. > > > A separate file to store the LU metadata would solve these issues. > > If you are going to be doing that for these reasons, does it make > sense to have two different formats for iSCSI disk images, one with > the metadata included and one with it separate? I could see this > leading to unnecessary confusion and complexity. Why not just go > for the separate metadata file case now? We have debated over that approach for some time and the 2 file approach has its own set of administrative issues which prevented us from making this the only choice to store LU metadata. While it does help in certain scenarios, there are various other scenarios around back end migration and crash recovery where the administrators may not like to have to manage additional metadata files in addition to their raid volumes contain the LU data. Sumit From John.Forte@sun.com Wed Apr 9 11:25:37 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m39IPaqb026617 for ; Wed, 9 Apr 2008 11:25:37 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m39IPRIE024993 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Apr 2008 19:25:35 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JZ200I11LUMUW00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 09 Apr 2008 11:25:34 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JZ200IXOLUME900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 09 Apr 2008 11:25:34 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m39IPYdC000401 for ; Wed, 09 Apr 2008 18:25:34 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JZ200801JU2J800@mail-amer.sun.com> (original mail from John.Forte@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 09 Apr 2008 12:25:34 -0600 (MDT) Received: from [129.146.56.52] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JZ200KMXLTV0940@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 09 Apr 2008 12:25:07 -0600 (MDT) Date: Wed, 09 Apr 2008 11:22:25 -0700 From: John Forte Subject: PSARC/2008/235 SCSI Block Disk Provider for COMSTAR Sender: John.Forte@sun.com To: Sumit.Gupta@sun.com Cc: PSARC-ext@sun.com Message-id: <47FD0961.7060905@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.4 (X11/20070723) Status: RO Content-Length: 52 This fasttrack was approved in PSARC today. - John