Mark A. Carlson wrote: > > > > Hi Bill, the user space code works just fine and comes into the picture later when the root is already mounted. iscsi driver plumbs the interface and brings the network up during the mountroot operation itself. It uses ldi_vp_from_name() to create a vnode prior to modrootloaded.
I have a system booted up and running with all the networking user/kernel code working fine. All the code changes are confined to iscsi driver and there are no interface/architectural changes. Thanks, Sajid > On Fri, 2007-08-03 at 14:41 -0700, Mark Carlson wrote: > >> 7. root disk is seen through regular NIC port >> > > There's a lot of detail left out here. > > last I checked, solaris's iSCSI runs over the solaris IP stack, not over > a raw NIC. > > A significant fraction of IP functionality (DHCP, IKE, routing, ipmp, > etc.,) involve significant amounts of user space code (commands and > daemons). Those daemons also make filesystem-related system calls and > do other things which may need disk i/o in normal operation. > > If one of those daemons accesses part of the filesystem backed by an > iSCSI disk, I'd expect some sort of deadlock will be possible (syscall > made by routing daemon can't make forward progress without block X from > the root volume; iscsi can't fetch that block without being able to > transmit IP packets to the server; IP packets can't reach that server > until the daemon reestablishes a working route to the server; daemon > can't reestablish a working route until the aforementioned syscall can > make forward progress...). > > I expect that running with an iSCSI root will have interactions with IP > which closely resemble operating with NFS diskless -- a capability that > is no longer actively used and which is not routinely tested. > > while it may be possible to boot off an iSCSI disk, I suspect that there > are a bunch of dragons lurking here with respect to running reliably off > of iSCSI in non-trivial networks. > > I'd feel a lot better about our ability to enumerate all these subtle > dependencies, gotchas, and limitations if this case got a full > (non-fasttrack) review. > > - Bill > > > > > > > > >
