SCSI Block Disk Provider for COMSTAR [PSARC/2008/235 FastTrack]

[Sumit Gupta]

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 <size>] <filename>
>> 	sbdadm delete-lu <lu_name>
>> 	sbdadm import-lu <lu_name>
>>         sbdadm list-lu
>> 	sbdadm modify-lu [-s, --size <size>] <lu_name>|<filename>
>>
>>
>> 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 <size>] <filename>
>>
>> 		Create a logical unit that can be registered with stmf(7D).
>>
>> 		-s, --size <size>
>>
>> 			<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, <size> defaults to
>> 			the size of <filename>.
>>
>> 			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