> On 2017-08-26, at 02:47, Michael van Elst <mlel...@serpens.de> wrote:
>
> sve...@viewmark.com (Sverre Froyen) writes:
>
>> The changes to librefuse last year require changes to iscsi-initiator. This
>> is because of argument changes for fuse_main. The symptom is a "fuse: no
>> mountpoint specifiedâ error. Has anyone looked at this?
>
> Probably not. Is there a reason to use that iscsi-initiator? The in-kernel
> one is much better.
The only reason was that I discovered the iscsi-initiator/iscsi-target version
first and they worked fine. Now, a quick test of the in-kernel version results
in a stream of
sd0(iscsi0:0:0:0): QUEUE FULL resulted in 0 openings
after a few seconds of stress (performing a "cvs update -dP” on the netbsd-7
branch). It this point, the machine is non-responsive until a reboot. Light use
seems to work OK.
My setup is as follows:
NetBSD-current VM running on a MacBook Pro OS X 10.12.6 under VMware Fusion.
10 GB filesystem image file on the Mac containing netbsd-7 served up using
netbsd-iscsi-target from pkgsrc (yes, iscsi-target is running on the Mac).
Previously I’ve used this setup extensively with iscsi-initiator and vnd on the
NetBSD VM.
I can always use NFS to provide the filesystem image files to the NetBSD. It’s
only about 10-20% slower but, for some reason, iscsi appeals to me as a
cleverer solution.
Regards,
Sverre
PS I was able to fix the fuse_main args issue by adding a conditional
opts.mountpoint = *argv;
in fuse_main_real. This makes iscsi-initiator start up. However, attempting to
use the remote file causes a hang in the read system call (perhaps another args
change).
PPS I notice that iscsi_initiator installs in /sbin whereas librefuse is in
/usr/lib. Seems like iscsi_initiator (and iscsi_target?) should be moved to
/usr/sbin.
