IDS restore uses link in place at the start time of a restore - Why?

IDS 9.21 on HP-UX 10.20. No kaio. For my interest's sake only really: I picked up an emergency call last night from a company in N America. Their elderly instance had crashed and their restores were failing. The reason for the failure was that Chunk 28 was on a failed disk. So I had them create a new Logical Volume on a good disk, then break the hard link to the LV on the failing disk and replace it with a link to the LV on the good volume. However, as it took about 50 minutes for the restore to get to Chunk 28 I had them kick it off *before* we had replaced the link for Chunk 28. By the time IDS got to Chunk 28 some 50 minutes later we had re-created the link to the "good" LV, but the the restore still failed, evidently having tried to write to the old link destination. Re-running the restore worked fine of course. This surprised me: onstat -D told me that Chunk 28 had not been touched prior to the restore crashing, so I was taken by surprise that IDS (or was it HP-UX) "remembered" the link that was in place at the time the restore started. Does anyone know why this was so? thanks Neil

Neil Truby wrote: > IDS 9.21 on HP-UX 10.20. No kaio. > > This surprised me: onstat -D told me that Chunk 28 had not been touched > prior to the restore crashing, so I was taken by surprise that IDS (or was > it HP-UX) "remembered" the link that was in place at the time the restore > started. Does anyone know why this was so? > Well as the restore checks the size and perms and ability to open each chunk when you start the restore - presumably by opening each chunk - well they are now open and ready to be written to. If the restore closed them it couldn't guarantee that it could open them for exclusive write 'later' -- Clive

"Clive Eisen" <clive@serendipita.com> wrote in message news:46cd670d$0$11445$db0fefd9@news.zen.co.uk... > Neil Truby wrote: >> IDS 9.21 on HP-UX 10.20. No kaio. >> >> This surprised me: onstat -D told me that Chunk 28 had not been touched >> prior to the restore crashing, so I was taken by surprise that IDS (or >> was >> it HP-UX) "remembered" the link that was in place at the time the restore >> started. Does anyone know why this was so? >> > > Well as the restore checks the size and perms and ability to open each > chunk when you start the restore - presumably by opening each chunk - > well they are now open and ready to be written to. > > If the restore closed them it couldn't guarantee that it could open them > for exclusive write 'later' OK, thanks, and thanks also to Marco who explained the same thing.