I have a oi_148a test box with a pool on physical HDDs, a volume in
this pool shared over iSCSI with explicit commands (sbdadm and such),
and this iSCSI target is initiated by the same box. In the resulting iSCSI
device I have another ZFS pool "dcpool".

Recently I found the iSCSI part to be a potential bottleneck in my pool
operations and wanted to revert to using ZFS volume directly as the
backing store for "dcpool".

However it seems that there may be some extra data beside the zfs
pool in the actual volume (I'd at least expect an MBR or GPT, and 
maybe some iSCSI service data as an overhead). One way or another, 
the "dcpool" can not be found in the physical zfs volume:

===
# zdb -l /dev/zvol/rdsk/pool/dcpool 

--------------------------------------------
LABEL 0
--------------------------------------------
failed to unpack label 0
--------------------------------------------
LABEL 1
--------------------------------------------
failed to unpack label 1
--------------------------------------------
LABEL 2
--------------------------------------------
failed to unpack label 2
--------------------------------------------
LABEL 3
--------------------------------------------
failed to unpack label 3
===

So the questions are:

1) Is it possible to skip iSCSI-over-loopback in this configuration?
Preferably I would just specify a fixed offset (at which byte in the
volume the "dcpool" data starts) and remove the iSCSI/networking
overheads and see if they are the bottlenecks.

2) This configuration "zpool -> iSCSI -> zvol" was initially proposed 
as preferable over direct volume access by Darren Moffat as the 
fully supported way, see last comments here:
http://blogs.oracle.com/darren/entry/compress_encrypt_checksum_deduplicate_with

I still wonder why - the overhead is deemed negligible and there
are more options quickly available, such as mounting the iSCSI
device on another server? Now that I hit the problem of reverting
to direct volume access, this makes sense ;)

Thanks in advance for ideas or clarifications,
//Jim Klimov


_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to