Here is a summary to our disksuite mirror problem.
We finally got this fixed by removing our Seagate disk
and replacing it with a SUN disk. We now have a SUN
to SUN mirror set. I assume a Seagate to Seagate mirror
set would have worked also, however, since these were the
boot disks, I opted to go with SUN here. All our other mirror
sets are with Seagates.
Although SUN claims mirroring to different manufactured disks
shouldn't be a problem, I thought in this case it was. Reason
being is the geometry between the two disks were different and it
was impossible to get the same disk partition sizes on both the disks.
The system has been stable for about a week now.
Original question follows.
> From: SIMEONE, Allan J.
> Sent: Thursday, March 04, 1999 1:58 PM
> To: 'Sun-managers@
> Subject: Mirror sets keep failing
> I'm new to the SUN operating system and I am having quite a bit of
> with the system we have here. I already have a call logged with SUN,
> the problem hasn't been resolved in about a month. I thought I would try
> next before I take the next step. SUN has been good trying to figure this
> but there just hasn't been a fix yet.
> Let me explain.
> I have a Enterprise server 3500 running Solaris 2.6. I have disksuite
> The system originally came with a 9 gig SUN disk which, of course, is the
> system disk. We decided we needed 5 more 9 gig drives and because of
> price, we decided to buy Seagates, which is what SUN disks are anyway.
> SUN support said this should not be a problem.
> We have a row of disks in channel 0 and a row of disks in channel 1.
> I mirrored the system disk (/, /var, /usr, swap) with a disk in channel 0
> and a disk in channel 1 using disksuite (version 4.2). The geometry
> between the two disks are different and the partition sizes are very
> The disk I mirrored to has a little bit bigger size partitions by a few
> due to this geometry.
> We have found if I do the find command (with or without a -mount parameter
> to any file on /usr, the mirror set will go into critical state and this
> is consistant.
> Only once, other mirror sets have gone into critical state also.
> SUN support believes the system disk mirror set could have triggered the
> other mirror sets that one time, so we are focusing on just the system
> mirror set. After the mirror sets go into critical state, I can simply
> do a
> metareplace -e to put the mirror set back with no problem until I/O goes
> to /usr again.
> To date we have done the following...
> swapped the one seagate drive (twice).
> Moved the seagate drive to a different slot on the same channel.
> installed the latest cluster patch for Solaris 2.6
> The problem still exists. The next step looks like installing another
> patch which looks like it is a firmware upgrade to the disks themselves.
> Before I take that drastic step, I would like to know if anyone else
> seen this problem or would have any insight on how to fix this.
> Theories are:
> 1)Backplane is has to be replaced, however, moving the disk to a different
> slot changes that theory.
> 2)Having the seagate drive mirrored to a sun drive although SUN says that
> is no problem.
> 3) replacing the GBIC's on channel 1.
> 4) replacing the cables to the GBIC's on channel 1.
> 5) replacing the I/O+ board the GBIC's connect to.
> I have a theory I should actually replace the SUN disk with another
> Seagate although the SUN disk never goes into critical state. Only
> the Seagate drive goes into critical state.
> Any comments welcome.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:19 CDT