> From: RPN01 > > The problem all this is trying to get around is that, if you > define a system that brings up, say, minidisks at 391, 392 > and 393, they become /dev/dasda, dasdb and dasdc. Now you add > a new minidisk at 291.... If the system puts this at the end > of the list, then it would become /dev/dasdd, and this would > happen when you add the disk into the running system. But, > what if, when you re-boot the entire image, it now finds this > disk first? It could become /dev/dasda, pushing the other > disks each up one letter, and causing your fstab and other > things to fail miserably.
We solved this problem by including "dasd=292-2FF" with the ipl parameters in zipl.conf -- I inherited this configuration and I suspect it was put into place before there was a mount by-path option. With this in zipl.conf, 292 is always dasda, 2A9 is always dasdx, etc. I have been aware of other installations where parameters like "dasd=293,292,294-2FF" were specified, so that 293 is dasda, 292 is dasdb, 294 is dasdc, and so on. No doubt they had their reasons, although it seems somewhat gratuitous to me. Solaris handles this problem very well, IMO---especially with the addition of Veritas Volume Manager. The Linux mount by-path does come close to giving Solaris-like behavior, but when I look sideways at it there's something I can't put my finger on which makes me not entirely sure I should convert my systems to it. Perhaps there's nothing there after all, but without our having a real problem to solve here, there's little reason to look closer. ok r.
