Quoth William D. Hathaway on Sun, Oct 29, 2006 at 03:41:01AM -0800: > I am working with a customer who has an iSCSI SAN and who over the > weekend upgraded a system from Solaris 8 to Solaris 10 update 2 and > added an additional T2000 with S10u2. Previously the customer was > using either QLOGIC iSCSI HBAs or Cisco's iSCSI software initiator > (both of which had varoius quirks and the iSCSI SAN vendor urged > them to move to S10's builtin initiator). One problem we ran into > is that if we have the iSCSI backed filesystems set to mount at boot > via vfstab, the filesystem/local service faults (saying it can't > mount the iSCSI filesystems). If I go over to the console a minute > later, I can clear the service and the mounts will come online fine, > so it seems like there is an initial timeout issue and there should > perhaps be an additional dependency or a change to the fs-local > method.
This sounds like a dependency coordination problem. By adding an iSCSI filesystem to vfstab, you have made filesystem/local dependent on the iSCSI service. But without adding a dependency to the repository, SMF doesn't know it, and starts it too soon. So right now, your customer should create a dependency in the filesystem/local service on the iSCSI service. Two questions to answer are 1. Should filesystem/local depend on iSCSI by default? 2. How can we make this easier to administer? The first seems like a tradeoff between how many people will put auto-mounted filesystems on iSCSI and whether a default dependency will slow down boot for people who don't. I don't have enough data to make this call -- it should be put to the iSCSI team. For the second, if there were a command interface to add filesystems to vfstab, then we could just have that command set the dependencies appropriately. Of course, we don't have such a command. It's also conceivable that we could have the filesystem/local service determine this dynamically when it starts. The framework hasn't really been design with this in mind, though, so it would take some ugly hacking, and probably wouldn't work very well. David
