Hi Spencer, Thanks for your reply, you mentioned that the mount code will retry the operation, how many retries will it attempt? I like to take a look at the code then.
I wonder if there is something (service) we can depend on to ensure a certain IP is accessible, but currently it seems not there. Thanks, Jack Spencer Shepler wrote: > > On Apr 1, 2008, at 3:03 AM, Jack wrote: >> Hi All, >> >> I'm meeting a problem with the routing discovery during booting-up and >> hoping to get some helps from this alias. I'll describe the problem >> below, please kindly share your thoughts on this if any. Thanks in >> advance. >> >> We're working on the iSCSI initiator in Solaris, it utilizes TCP/IP >> protocol in kernel (so*) to enumerate block devices on the local host. >> Users may need to access these block devices in an early booting up >> time, e.g., by mount points in /etc/vfstab, or use them as shared DID or >> quorum device in Cluster environment. >> >> However a problem here is that iscsi devices could be inaccessible >> during the boot time due to the route to the iSCSI target (probably in >> another subnet) is not established yet. That issue is getting hot since >> people keep asking to use iSCSI device on cluster environment. >> >> I'm curious about if NFS met this problem problem before and how got >> solved. Thanks. > > If the route is unavailable for an NFS mount, it will also have > a similar problem. However, the NFS mount code will retry a mount > if the server is not responding/unavailable. In general, routing > needs to be present/appropriate in the initial network configuration. > > Spencer >
