[svlug] Help connecting 60 Gig Raid Array

[Ben Spade]

Hi Alvin,

> 
> hiya ben..
> 
> > The storage space will be used for tools, all of those CDs one gets from
> > companies like Cadence or Synopsys, so in case of catastrophy, we could
> > simply re-install. Backups will be done to a DLT4700 tape jukebox - each
> > tape holds 20MB (40 compressed), so 2 or 3 partitions should be about right, 
> > and most of the time the array will be mounted read-only.
> 
> backing up 60Gb to 20 tapes is NOT easy....
Did I say 20MB - I really meant 20-40 Gig! Makes it a lot easier.

> 
> I'd NOT backup synopsys, cadence etc since it's vendor software that you
> installed from CD...
Right.
> 
> I'd make sure no one write "user data" to that drive...
Yep.

> 
> than a simple find "new files" will suffice for incremental backups 
> using the cdrom as the "full backup source to patch incrementally"
> 
> > One advantage of the IFT-3102U controller is that it is managed via RS232, so
> > it is OS indipendent. It can divide the physical array into logical units,
> > each of which can be Raid 0, 1, 3, 5, or JBOD (just a bunch of drives).
> 
> this is true of the h/w raid systems i meesed with...has rs232 port...
> 	( cmd, syred, ?? )
> 
> > So - more questions:
> > One of you suggested that partitions be no larger than the backup device.
> 
> no reason why not...since the "backup" is the installation cdrom...
> and  can do incremental backups from the date of the installs..
> 
> > OK, should I treat the array as one huge logical unit, and partition it
> > the way we normally do, or should I break the array into multiple LUNs
> > (which would allow me more partitions, but the multiple LUNs will confuse
> > me, if not Linux).
My cohorts want to make just one big partition, so I think that is what we
will do.

> 
> we used channel-a and channel-b on cmd and syred and it confused the
> system really bad....
> 	raid# cp 1Gb_binary.file  another_test.file
> 	raid# sync
> 	raid# diff 1Gb_binary.file another_test.file -->>FAILS<<--
I guess I don't understand what you are saying here.

> 
> > We currently have Slackware, RedHat, and SuSE systems here - any comments?)
>  
> I use rh-5.x and the raid box is treated as a regular scsi device...
> all the "raiding" is done internally to the raid box...
> 
> > About the IFT controller - anyone have any experience with them? What are
> > the alternatives if this works well enough that management wants to do it
> > again?  Alvin mentioned the BT958 - we want to support the Buslogic folks
> > (whatever they are called today), how does one manage the BT958? A card
> > seems less versatile than a stand alone array, too.
> 
> since the raid box we have are just like a simple scsi device...
> a simple scsi or differential scsi controller works fine (flawlessly) for us...
> ( it is used as /home for all the users...so if something went wrong... 
> ( guess I'd hear about lost files etc...
> 	- and yes...I took out the adaptec 2940uw that used to drive it...
> 	- too many scsi timeouts and stalled "edits"..than bursts...
So what was wrong with the 2940UW? What did you replace it with?

> 
> > > - If your partition gets hosed you lose 60G of data
> > > - If you have to fsck, you can go for lunch and come back.
> 
> yup...takes me about 45 minutes on a P200 for that size raid box
Sounds painful. I expect that we will have it mounted read-only most
of the time - with a UPS, etc. 

> 
> Personally... I think it's better to have two "mirrored" mirrored
> and stipped  linux systems than to have a expensive hardware raid ( $20K ? ) 
How do you mirror them?

> 	- you have built-in backups
> 	- you have "hardware balancing" for the computational cpus
> 	- you have more headaches if not careful !!! :-)
> 
> have fun
> alvin
> 
	Thanks,
	Ben


-- 
    Ben Spade                   President, Silicon Valley Linux User's Group
  spade at spade.com                              spade at svlug.org
http://www.spade.com/                        http://www.svlug.org/
~



--
echo "unsubscribe svlug" | mail majordomo at svlug.org
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ to unsubscribe