Re: Boot Error on Shadowed Sys Disk.
- From: dave.baxter@xxxxxxxxxxxxxxxx
- Date: 2 Feb 2006 11:14:49 -0800
I dont think the problem is a "path definition" issue, several
successful boots had already been done, and even on the failed boot,
the booting system had a) found the device, b) read in the system
parameters and bootstrap code, and joined the cluster (as the correct
system).
I do however, think your first sentence pinpoints the issue, i.e. "must
have access to all shadow members at boot time". My logic goes like
this.
At the lowest level, the boot path is just a path to a "raw device",
and until the new node "joins" the cluster, the other nodes (and
processes running on them) are unaware of the new node. Once the new
node is "a member", and the other nodes recognise his presence, the
situation changes.
For example, the node which is up and which is controlling the
shadowcopy, may recognize that some process is trying to access the
system disk, but will not (or maybe cannot) concede access because the
new node may not yet have a SHADOW_SERVER process to talk to.
This being the case, the controlling node might conceivably put the
disk in "Mount Verify" until the situation is resolved.
The resolution would likely only occur if
1) The booting node time's out/bugchecks, hence stops trying to
access the disk.
2) The shadowcopy ends, taking away the restriction and allowing the
booting node access.
3) The Mount Verify times out resulting in (probably) the ejection of
the disk which is the target of the copy and then to option 2.
does this make any sense, and more importantly, does it have any
validity???
Dave
.
- References:
- Boot Error on Shadowed Sys Disk.
- From: dave . baxter
- Re: Boot Error on Shadowed Sys Disk.
- From: mckinneyj
- Boot Error on Shadowed Sys Disk.
- Prev by Date: Re: FOR070.DAT files appearing
- Next by Date: Re: null terminated strings
- Previous by thread: Re: Boot Error on Shadowed Sys Disk.
- Next by thread: Re: Boot Error on Shadowed Sys Disk.
- Index(es):
Relevant Pages
|
