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

[Andrew Gabriel]

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