> The popular solutions I've seen are: > > 1) Random bytes, or fixed id + random bytes. Even on a worldwide net, > collisions are highly unlikely. The problem is that the random bytes are not necessarily random; especially not at boot: get_random_bytes gets its randomness from the entropy pool. The pool starts with the time of the day and some always the same data and then gets feed by time stamps from a few interrupts. This doesn't include network interrupts (or rather only a small handfull of network drivers set the flag -- but at early boot you don't have any network anyways), but is primarily keyboard/mouse and storage interrupts. On headless systems typically only storage interrupts. Now do you see the problem with using get_random_bytes() to get your storage working? In many cases the time of the day in the pool will prevent the worst, but if you have a cluster where all boxes boot at the same time it's quite likely your early randomness will be all the same.(ok cluster boots are usually staggered, but you still have a large number of systems booting at the same time) The whole thing would probably work if you could mix something machine unique into the entropy pool at boot (e.g. a network mac address); but Linux can't do that do to boot strap ordering issues. I agree with the people who say this is a highly dangerous thing to do. It is much better to fail clearly that to create a hard to debug subtle problem in a storage network. If you have prototype hardware that doesn't supply an unique ID then I would suggest you add some module parameter to allow choosing a unique (or even random) one. But don't make it default. -Andi - 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
