Re: iscsifs

[brook%biology.nmsu.edu@localhost (Brook Milligan)]

Stephen Borrill writes:
 > Yes, it would. And going onto your later question about rc.d scripts, it 
 > would make that job easier. I've got a stack of changes to submit to 
 > iscsi-initiator (new name for iscsifs), so I'll add that to the list.

Perhaps this is obvious, but you would want to capture the pid in a
file, too, for later killing.

 > I bet this is because it's resolving to ::1 (IPv6), but the target isn't 
 > bound to that.

Perhaps.  However, with the -4 command line option it still does the
same thing.  Shouldn't that resolve to 127.0.0.1?

 > There are a couple of problems with the vnd approach. If the target dies, 
 > then it leaves the initiator side in a horrible mess. The initiator 
 > doesn't attempt reconnection, the vnd is still configured but backed by 
 > nothing. When this happens it can be impossible to cleanly shut the 
 > machine down.

Could this be addressed in any way?  For example, what if a signal
(HUP?) to the initiator caused it to reconnect?  Or could it be done
like soft nfs mounts so that accesses fail cleanly after a timeout?

 > iscsifs does have the option to generate device files, but to be of any 
 > use there is no point in just creating one - we really need both 
 > character and block device nodes to be created as well as nodes for the 
 > disklabel slices on the device.

I tried to look at what iscsifs does when it creates block or
character devices.  I presume that an application can open those
devices and work with them.  However, it is unclear to me how one
would use those to provide a disk device interface other than by
layering a vnd device over them.  Perhaps I'm missing something,
though.

It would seem really useful, though, to be able to use the storage
available through iscsi as something that can be mounted onto the
filesystem.  What is the best way to accomplish that?

Cheers,
Brook