As it occasionally happens, this is not another whining question
from me but rather a statement. Or a progress report.
It recently occurred to me that since I fail to work around my
home NAS freezing while it tries to import the "dcpool" of my
setup, and the freeze seems to be in-kernel, I can try to offload
this job to another kernel - running in a VM which is much easier
to reboot.
Discussion of my CPU on the list was rather valid: it does not
support virtualization and happened to be rather slow (taking
several minutes to boot the VM, a lot more to install it, etc.)
although not peaking in "top"/"prstat" during most tasks.
What's worse, VirtualBox only allows running 32-bit VMs on this
hardware, and after spending much of the night installing the
VM and configuring an iSCSI target, I ran into an error like
"iSCSI device too big for a 32-bit kernel". Bummer.
Luckily, my home have a fast uplink with free 100Mbit bandwidth
to my work (sitting in one town with one ISP) and transferred
this VM from home-NAS to my office computer (more modern and
performant), and fired it up there. Came up 64-bit, as expected
and seeing the 8 cores and 8Gb RAM provided (alas, can't get
more than that - stock VirtualBox does not allow faking virtual
RAM with host's on-disk swap, which would help in this situation
a lot, since zpool import doesn't want to swap out).
Still, after configuring the relevant IP addresses I could not
get the iSCSI connection running. I had opened ports 3260 and
3205 tcp/udp on my home firewall/nat/router appliance, and I
snooped dialogs of traffic on both sides, but no iSCSI.
Jun 16 01:03:01 bofh-solv iscsi: [ID 933263 kern.notice]
NOTICE: iscsi connection(8) unable to connect to target
iqn.1986-03.com.sun:02:380c2eb8-4a4a-6e78-e304-c8cd5e29a7a4
After a while I stumbled upon the command:
# iscsiadm list discovery-address -v X.X.X.X (home public ip)
...and it happily reported:
Discovery Address: X.X.X.X:3260
Target name:
iqn.1986-03.com.sun:02:380c2eb8-4a4a-6e78-e304-c8cd5e29a7a4
Target address: 10.94.56.99:3260, 1
Target name:
iqn.1986-03.com.sun:02:380c2eb8-4a4a-6e78-e304-c8cd5e29a7a4
Target address: 192.168.56.1:3260, 1
Target name:
iqn.1986-03.com.sun:02:380c2eb8-4a4a-6e78-e304-c8cd5e29a7a4
Target address: 10.94.56.59:3260, 1
So the iSCSI server (target) reports the system IPs it
sees, and asks the clients to connect to them.
Just in case this helps anybody - I added the public IP
address as an alias on the home-NAS loopback device:
# ifconfig lo0 addif X.X.X.X/24 up
and my iSCSI device quickly appeared in the remote VM!
So now it is trying to "zpool import dcpool" which is
* a ZFS pool
* backed by a ZFS volume in a physical "pool"
* available over iSCSI
* being imported by a VM running across town
* through NAT
Hopefully this adventure won't crash my home-NAS box,
and would let the "dcpool" clean up its deferred-free
problems - however long it takes - but with minimal
hands-on or running around to reboot, physically...
//Jim Klimov
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
