cc''ing to storage-discuss where this topic also came up recently.
By default for most backing stores, COMSTAR will put its disk metadata
in the first 64K of the backing store as you say. So if you take a
backing store disk that is in use as an iscsitgt LUN and then run
"sbdadm create-lu /path/to/backing/store", it will corrupt the data on
the disk. Don''t do this!
There are two enhancements that were introduced with the putback of
PSARC 2009/251 in snv_115 that may be helpful. See stmfadm(1m) for details
* If the backing store is a ZVOL, the metadata is stored in a
special data object in the ZVOL rather than overwriting the first
64K of the ZVOL.
* the command "stmfadm -o meta=/path/to/metadata-file create-lu
/path/to/backing/store" can be used to redirect the metadata to a
named file on the target system.
Here is the relevant paragraph from stmfadm(1m):> Logical units registered with the
> STMF require space for the metadata to be stored. When a
> zvol is specified as the backing store device, the
> default will be to use a special property of the zvol to
> contain the metadata. For all other devices, the default
> behavior will be to use the first 64k of the device. An
> alternative approach would be to use the meta property
> in a create-lu command to specify an alternate file to
> contain the metadata. It is advisable to use a file that
> can provide sufficient storage of the logical unit meta-
> data, preferably 64k.
If you use the -o meta=file approach, remember that if the volume moves
its metadata must move along with it. Remembering this external
linkage could become a long-term hassle. Some have opted to create new
LUNs and then copy the data over, so they can remove their dependency on
this external metadata file.
You asked only about migrating the *DATA* from iscsitgt to COMSTAR.
This part is doable, given the above tools.
What is not supported is automatic migration of the target and LUN
*definitions* from iscsitgt to COMSTAR. The iscsitgt uses a "one target
per LUN" model. The COMSTAR model is more like "all the LUNs visible
through the same target", using initiator-specific Views to control
access. Creating an automated tool to go between these very different
approaches would probably do more harm than good. You are better off
creating a new set of LUN and Target definitions to match the new
environment. It is up to you.
Peter
On 09/21/09 04:29, Markus Kovero wrote:>
> Is it possible to migrate data from iscsitgt for comstar iscsi target?
> I guess comstar wants metadata at beginning of volume and this makes
> things difficult?
>
>
>
> Yours
>
> Markus Kovero
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>