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):
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.
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.
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.
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
zfs-discuss mailing list
storage-discuss mailing list