2012-10-04 16:06, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) пишет:
From: Jim Klimov [mailto:jimkli...@cos.ru]
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.
Ick. And it worked?
Um, well. Kind of yes, but it ran into many rough corners -
many of which I posted and asked about.
The fatal one was my choice of smaller blocks in the zvol,
so I learned that metadata (on 4k sectored disks) could
consume about as much as userdata in that zvol/pool, so
I ultimately migrated data off that pool into the system's
physical pool - not very easy given that there was little
free space left (unexpectedly for me, until I understood
the inner workings).
Still, technically, there is little problem building such
a setup - it just needs some more thorough understanding
and planning. I did learn a lot, so it wasn't in vain, too.
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 started looking at that yesterday, and was surprised by how complex the
dependency graph is. Also, can't get graphviz to install or build, so I don't
actually have a graph.
There are also loops ;)
# svcs -d filesystem/usr
STATE STIME FMRI
online Aug_27 svc:/system/scheduler:default
...
# svcs -d scheduler
STATE STIME FMRI
online Aug_27 svc:/system/filesystem/minimal:default
...
# svcs -d filesystem/minimal
STATE STIME FMRI
online Aug_27 svc:/system/filesystem/usr:default
...
In any event, rather than changing the existing service dependencies, I decided
to just make a new service, which would zpool import, and zpool export the
pools that are on iscsi, before and after the iscsi initiator.
At present, the new service correctly mounts & dismounts the iscsi pool while
I'm sitting there, but for some reason, it fails during reboot. I ran out of time
digging into it ... I'll look some more tomorrow.
That's about what I did and described.
I too do avoid hacking into distro-provided services, so
that upgrades don't break my customizations and vice-versa.
My code is not yet accessible to me, but I think my instance
of the target/initiator services did a temp-enable/disable of
stock services as its start/stop methods, and the system iscsi
services were kept disabled by default. This way I could start
them at a needed moment in time without changing their service
definitions.
Also note that if you do prefer to rely on stock services, you
can define reverse dependencies in your own new services (i.e.
"I declare that iscsi/target depends on me. Yours, pool-import").
HTH,
//Jim
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
