Where can I find info for the MSS 1600 regarding rebuilding the array?

Possibly in the manual -- copy of it here.

Page 112 may be a good place to start.

Thanks bittmann! I didn't have this manual.

I did what it says, but the rebuild process dies at about 19% completion. However, I don't think it's really rebuilding because there's no drive activity on the rest of the array during the rebuilding. I'm not Unix savvy, but is there something in array_services that might help determine what's not right? I'd like to avoid formatting the array if it's possible.

 -Mark

No idea here.  Never seen that beast.

You sure that you only have 1 drive that's knackered?  If the array is borked, it won't be able to rebuild at all.

Yup. All other drives in the array show no errors when I click on them and the server runs fine, otherwise. Is there a windows equivalent to CHKDSK in Unix that I can safely use?

Again, no idea about your box in particular, but "fsck" or one of its filesystem-specific derivatives could be involved.

What OS does that system run on?

 

Edit:  Nevermind, looks like HP Realtime.  Sound about right?  

It runs Unix. It has a Windows GUI as described in the manual. The error window that pops up after a rebuild failure says nothing about why it failed, only THAT it failed. Is there a log file I should search for the failure code?

Wish I could cut-n-paste this, but it won't go.  From page 7-30 of this document:

to run fsck on HP-RT OS (note that to do this you have to be SIGNED ON AS ADMINISTRATOR TO THE UNIX SYSTEM ITSELF):

 

fsck block-device

 

where block-device is the name of the device file for the drive you are attempting to check  (usually something like /dev/hda1 or some such, but no idea what it is on your box).

Usually you want to run this on an unmounted filesystem, or at the least, a read-only filesystem.  So, if you don't know how to do THAT, more research will be needed.  You're playing with something that fiddles with the low-level attributes of your filesystem...powerful stuff.

Scared yet? 

 

And to answer your question about logfiles, etc. -- no idea again.  IF you can log on to your MediaStream Server as the root user, you can look at quite a bit of info.  If all you have is a Windows gui-ized peephole to peer into the innards of your box, you're at the mercy of the GUI.

Hmmm---I wonder where you could go to get help from someone who HAS seen this box.  Any user forums that you know of (even if they're non-Pinnacle)?  This one is pretty preoccupied with Studio and consumer stuff.  Unless maybe you can get the attention of someone from the Liquid (semi-pro to Pro side) of the equation...

BittMann

Scared? Me? Yes, indeed!

I can log into the Unix shell as root. I can make my way around the file system as far as changing directories and reading file contents. You sent what looks like the correct document...when the server restarts, I can watch the startup via the GUI and it is running HP-RT OS. The array has 9 drives in it numbered 1-9. Disk 8 is the one reported as "failed". I've replaced the drive, but I can't determine if the OS or the array sees the replacement. When I click on "Rebuild", acording to the manual you sent earlier, #8 drive looks like it's rebuilding, then reports as "Failed" after about 19% of the task.

I'll take a look at the new document to see if that can help me diagnose the problem. 

I really appreciate your assistance. Please let me know if you think of something else I might try.

-Mark

Man, if you get all the way to 19% of a rebuild, then the system HAS to have seen the drive -- right?

Unless the new drive is bad, I suppose...what are the chances of that?

I dont' have much hope for fsck...even if the filesystem is screwed up (filesystem checking is all that fsck does), the array should still rebuild -- in theory, anyhow.

Hmmm...Are these SCSI drives?  Do you have another machine with an available SCSI interface that you can throw the new drive in to make sure it's not bad as well?  If it survives a format e.g. in NT, you should then be able to replace it in the HP and attempt another rebuild...and if it won't format successfully in NT, you know the drive is knackered.

Well, I thought it would have seen the drive by 19% of the rebuild, however, I remember (in previous rebuilds) the other drives in the array having drive activity during the rebuild, too. It's not doing that part this time around.

I received a box of four replacement drives, they've all failed, but I'll try your idea of putting them into another scsi-based system and try formatting them there. I'll let you know how that turns out either way. Thanks!

No idea what's happening during your rebuild, but if the first step of the rebuild is to do a verification of the drive and the drive "fails" for whatever reason -- too small, too big (in some cases), bad sectors, bad interface, etc. then that could be why you aren't seeing activity -- you didn't get far enough to START the rebuild process before you fell over.

Boring story -- we have an ancient RS/6000 here that's running with a mirrored OS drive.   One of the 2 drives in the mirror set died.  No problem, we're under IBM hardware maintenance, and they quickly showed up with a new drive, free with physical installation included.  Unfortunately, the new drive is twice the size of the old drive -- the old drives are no longer available through IBM, no way, no how.  Unfortunately, it's impossible to format said drive with the same cluster size as the existing drive....the machine insists upon allocating the whole darned drive, and when it does so, it requires a cluster size that's twice as large as the existing drive's geometry.  So, it will not, under any circumstances, allow me to mirror to that drive, period.  Can't even tell it to use the old cluster size and cut off the top half of the drive (which should work in theory) because the routines won't allow me to NOT use the entire drive.  Grrr.....Now, IBM would be happy to sell me  a matching "too big" drive if I didn't mind having to save/restore my boot partition to get it to work.  Gee, thanks.  Ultimately, we went through a 3rd-party channel and purchased a matching "old small" drive at our own expense.  Actually, we purchased 2, just in case...

Anyhow, the moral to the story is, at least for some machines in some situations, sometimes you HAVE to make sure that the drive geometry is compatible when replacing a drive in a RAID set.  Even when it doesn't strictly make sense that it should have to.

BittMann

I've ran into a similar situation here. I used DriveImageXML on a 200GB drive that had only the OS on it (using about 10%). When I tried to restore the image to another 200GB drive it failed, claiming the drives weren't the same size. Each drive was identical in size, but one was a Hitachi, the other was a Maxtor. There was just enough difference somewhere that the restore failed.

I need to dig up an old server to try formatting these silly drives.

 

Whenever I build a mirror set on my home machines, I always reserve the top 4 gig or so of the disk (I use that space to add to swap).  That way, if the new drive is something silly like 16 sectors shorter than the old drive, that's OK -- I still have 4 gig's worth of sectors to play with.

Good luck.