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

[Sumit Gupta]

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