Jeff Garzik wrote: > James Smart wrote: >> Uh, although this may work very well for small constrained configs, as one >> who debugs larger environments (and things always grow or get connected in >> ways you don't expect), depending on a random number for uniqueness makes >> me very unsettled. Debugging that small-percentage potential, when/if it >> does occur can be an absolute nightmare with all kinds of weird behavior. >> Rarely will you solve it from the context of a single server. There are >> lots of ways to cheat, but I believe they all have to be based on some >> small part that is guaranteed to be unique (like the IEEE id's). > > That's the ideal world, sure :) > > But the reality is, just like with ethernet MAC addresses, you don't always have one when you "supposed to" have one. > I'm curious about the problem you're trying to solve. Generally a missing WWN, as having a unique WWN should be a product requirement, is an indicator of a problem. Shouldn't the proper solution be to have the card repaired? Arbitrarily assigning a WWN could mask or introduce other problems, in particular with regard to storage connectivity. > There are obvious limitations and problems arising from a generated WWN -- particularly for an HBA, where serial numbers and other unique identifiers are scarce. But that doesn't wish the missing-WWN problem away. Decades of networking experience have taught us a few things :) > > As an aside, we also need a way to override the HBA's WWN, just like we do with ethernet MAC address. We do? Perhaps if it's corrupt and you know the correct value. But, in that case shouldn't the card be replaced? When would you need to override the default WWN? Linux: it's not just for desktops anymore. :) Mike > > Jeff > > > - > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html