Maurilio,
I'm trying to set up a proof-of-concept pc using commodity hardware,
I don't have that configuration (the one that gave those problems
with COMSTAR) anymore but I suspect that I was using /dev/zvol/dsk
and not /rdsk/.
Using 'dsk' over 'rdsk' should only impact performance, not
functionality.
Right now I have an HP ML310G5, quad core xeon, 8Gb ram, with a
couple of LSISAS3141E controllers which drive a zpool made of 4
vdevs each made of a mirror of two disks, since I've found out that
an iscsi booted pc does mostly small random IOs (a lot of them).
Client PCs are HP dc7600USDT with 2Gb ram and a PIV 3GHz, I need to
able to boot and hadle from 10 to 15 of them.
I'm creating sparse and compressed volumes, right now of 10Gb of
size, but the good ones will be 150Gb in size. Those pc will be used
by a hot-line office, so they should not be doing a lot of disk
activity; I mean, I'm not doing video composition on each pc or the
like.
In the coming days I'd like to test COMSTAR again, but I have a
second problem to 'solve', that is: I've installed a real PC, dd-ed
its HD to a zvol and I want to clone this zvol for every other pc
that I'll be booting off this iscsitarget.
Using COMSTAR, though, I'd end up cloning the first 64Kb of the
first zvol as well and I don't know if this can confuse sbdadm when
I create a lu from the cloned zvol (maybe I could zero-out the
cloned zvol before creating a new lun, I'll do some tests).
Just because you have awareness that COMSTAR's LUNs are backed up by
ZVOLs, and that as a root user you can read and write to these ZVOLs
directly, you should not. For the current version of COMSTAR, this is
why you are running in this first 64kb issue, as set of blocks that
are hidden from all supported SCSI initiators. Of course in addition
to the COMSTAR data, there is 'fdisk' partition data, maybe EFI disk
labeling, reserved sections, etc., etc., and finally the actual usable
space on the backing store device. There is a lot of opportunity to
overwrite required disk / volume data structures, so I would avoid
doing I/O directly to the ZVOL in use by COMSTAR.
Instead, access these COMSTAR LUNs using a supported SCSI Initiator,
which based on this thread of discussion is the iSCSI initiator. If
the COMSTAR LUN is going to be used on OpenSolaris, the connecting via
the loopback interface works well (127.0.0.1), or use VirtualBox, xVM,
VMware, etc., and the operating system of your choice, and its iSCSI
initiator software to access the COMSTAR LU.
- Jim
This is more or less what I'm trying to accomplish.
Maurilio.
PS. I've found, trying to "replicate" :) high end Sun's storage
systems, the HyperDrive5 (look for it in google) ram disk, as a way
to reduce zil activity and maybe as an l2arc, and I'm pondering
whether to buy it or not.
P.S.S. If you have the money, this is an awesome device. Unfortunately
with any leading edge storage technology like this, the instant you
purchase your HyperDriver5, the next generation (HyperDrive6 ?),
becomes available, being a cheaper, fast, bigger, ... whatever,
version. Sigh!
--
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
