curt@oce.orst.edu (Curt Vandetta) (11/14/90)
Hello folks, I've just had an experience that I thought some of you might benifit from hearing about. dump and restore have some serious problems with CDF's (Just in case you don't know, CDF's are Context-Dependent Files and used in HP clusters ) I don't think that the problem here is with dump, but it might be. Some background before I get started. I had a bad root disk. I did a complete level 0 dump of /, got my HP CE in to fix the disk and he ended up replacing it. At this point I figured no problem, boot the recovery system and restore from my dump image. Well it turns out that didn't work. (Long details about a recovery system hacked to work on an optical making the machine panic, are being skipped :-) So I was forced to re-install HP-UX 7.0 onto the new root disk, then restore over the top of it, from my dump tapes. Which brings me to the first problem. This one was really just a lack of fore sight on my part. What I did was start the restore process on my root disk, without first converting the newly installed HP-UX 7.0 root disk to a Cluster-Server. Which meant that none of the CDF files existed. Best told through an example. /etc/inetd.conf is a file on a Standalone machine, and a CDF on a diskless server. I was restoring a dump image taken from a diskless server onto a standalone machine. So when restore tried to create the directory /etc/inetd.conf+ it failed because /etc/inetd.conf already existed. This same problem happening on virtualy all of the CDFs put the machine a completly hosed state so I started over. Re-installed HP-UX 7.0 again. This time I converted the standalone system to a diskless server, then restored from tape. Expecting all of the CDF directories to be in place and for the restore to work. Well this time the REAL problem occured. Lets again explain by example. /etc/inetd.conf is now a CDF /etc/inetd.conf+/sylvestr where sylvestr is my hostname. Now when restore tried to write the file /etc/inetd.conf from tape to the disk it had it on the tape as /etc/inetd.conf+/sylvestr and the restore program wrote it to /etc/inetd.conf+/sylvestr/sylvestr which I think means that the OS saw the /etc/inetd.conf+/sylvestr on the tape and expanded the /etc/inetd.conf part of the path first then restored it, instead of taking the path as an absolute path. Which meant that the directory sturcture of all my CDFs was /path/CDF+/sylvestr/[sylvestr,tweety] (tweety is diskless) instead of /path/CDF+/[sylvestr,tweety] - and it was - /path/CDF+/localroot/[localroot,remoteroot] instead of /path/CDF+/[localroot,remoteroot] Anyway the jest of this story is that dump/restore and CDFs don't mix. This probably wouldn't have been a problem, had I not been restoring over the top of an existing root partion. (And I use the term "partion" very loosly :-) Which brings me to another question. Why doesn't HP support a "mini-root". If I would have had on of those, dump and restore would have worked very well with the CDFs, because they are written on dump image with the correct path, (/path/CDF+/[clusternames,...]) it appears that the problem is with the expanding of the path before it is written back to the disk. Just some thoughts, Curt -------------------------------------------------------------------------- Curt Vandetta College of Oceanography curt@oce.orst.edu Oregon State University
glen@hpfcmgw.HP.COM (Glen Robinson) (11/15/90)
I'm making an assumption here that you are on a S300 running 7.0. If that is the case I recommend that you check with your CE and/or the Response Center to verify that your system has the relevant SCSI and dump/restore patches installed. Glen Robinson The usual disclaimers about this not being an official statement etc.
dougf@mdavcr.UUCP (Douglas Floer) (11/16/90)
In article <1990Nov13.205051.21437@scion.CS.ORST.EDU> curt@oce.orst.edu (Curt Vandetta) writes: > > dump and restore have some serious problems with CDF's (Just in case > you don't know, CDF's are Context-Dependent Files and used in > HP clusters ) I don't think that the problem here is with dump, > but it might be. > We've just run into this same problem using dump/restore on a 9000/400 running 7.0. I find it incredible that HP would ship restore with such a known limitation and not mention it anywhere. Would like to hear from HP on this one. In our case it's doubly hard to take because it was the HP CE that caused the disk to crash by leaving off the SCSI terminator. No mention of compensation or even an apology from HP, either. -- Doug Floer, MDA, Richmond, BC, Canada ..!uunet!van-bc!mdavcr!dougf