2012-10-03 22:03, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) wrote:
If you are going to be an initiator only, then it makes sense for
svc:/network/iscsi/initiator to be required by svc:/system/filesystem/local
If you are going to be a target only, then it makes sense for
svc:/system/filesystem/local to be required by svc:/network/iscsi/target
Well, on my system that I complained a lot about last year,
I've had a physical pool, a zvol in it, shared and imported
over iscsi on loopback (or sometimes initiated from another
box), and another pool inside that zvol ultimately.
Since the overall construct including hardware lent itself to
many problems and panics as you may remember, I ultimately did
not import the data pool nor the pool in the zvol via common
services and /etc/zfs/zpool.cache, but made new services for
that. If you want, I'll try to find the pieces and send them
(off-list?), but the general idea was that I made two services -
one for import (without cachefile) of the physical pool and
one for virtual dcpool, *maybe* I also made instances of the
iscsi initiator and/or target services, and overall meshed
it with proper dependencies to start in order:
OS milestone svcs - pool - target - initiator - dcpool
and stop in proper reverse order.
Ultimately, since the pool imports could occasionally crash
that box, there were files to touch or remove, in order to
delay or cancel imports of pool or dcpool easily.
Overall, this let the system to boot into interactive mode
and enable all of its standard services and mount the rpool
filesystems way before attempting risky pool imports and iscsi.
Of course, on a particular system you might reconfigure SMF
services for zones or VMs to depend on accessibility of their
particular storage pools to start up - and reversely for
shutdowns.
These sorts of problems seem like they should be solvable by introducing some
service manifest dependencies... But there's no way to make it a
generalization for the distribution as a whole (illumos/openindiana/oracle).
It's just something that should be solvable on a case-by-case basis.
I think I got pretty close to generalization, so after some
code cleanup (things were hard-coded for this box) and even
real-world testing on your setup, we might try to push this
into OI or whoever picks it up. Now, I'll try to find these
manifests and methods ;)
HTH,
//Jim Klimov
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
