building a RAID system - yup

[Alvin Oga]

hi ya mark

On Wed, 8 Oct 2003, Mark Hahn wrote:

> > 	- get those drives w/ 8MB buffer disk cache
> 
> what reason do you have to regard 8M as other than a useless
> marketing feature?  I mean, the kenel has a cache that's 100x
> bigger, and a lot faster.

for those squeezing the last 1MB/sec transfer out of their
disks ... 8MB did seem to make a difference
	( streaming video apps - encoding/decoding/xmit )

> > 	- slower rpm disks ... usually it tops out at 7200rpm
> 
> unless your workload is dominated by tiny, random seeks,
> the RPM of the disk isn't going to be noticable.

usually a side affect of partitioning too

> > 	- it supposedly can sustain 133MB/sec transfers
> 
> it's not hard to saturate a 133 MBps PCI with 2-3 normal IDE
> disks in raid0.  interestingly, the chipset controller is normally
> not competing for the same bandwidth as the PCI, so even with 
> entry-level hardware, it's not hard to break 133.

super easy to overflow the disks and pci .. depending on apps

> > 	- if you use software raid, you can monitor the raid status
> 
> this is the main and VERY GOOD reason to use sw raid.

yup
 
> > 	- some say scsi disks are faster ... 
> 
> usually lower-latency, often not higher bandwidth.  interestingly,
> ide disks usually fall off to about half peak bandwidth on inner 
> tracks.  scsi disks fall off too, but usually less so - they 
> don't push capacity quite as hard.

scsi capacity doesnt seem to be an issue for them ... 
they're falling behind by several generations
( scsi disks used to be the highest capacity drives .. not any more )

> > 	- it supposedly can sustain 320MB/sec transfers
> 
> that's silly, of course.  outer tracks of current disks run at 
> between 50 and 100 MB/s, so that's the max sustained.  you can even
> argue that's not really 'sustained', since you'll eventually get
> to slower inner tracks.

yup ... those are just marketing numbers... all averages ...

and bigg differences between inner tracks and outer tracks

> > independent of which raid system is built, you wil need 2 or 3
> > more backup systems to backup your Terabyte sized raid systems
> 
> backup is hard.  you can get 160 or 200G tapes, but they're almost 

to me ... backup of terabyte sized systems is trivial ...
	- just give me lots of software raid subsystems
	( 2 backups for each "main" system )

	- lot cheaper than tape drives and 1000x faster than tapes
	for live backups

	- will never touch a tape backup again ... too sloow
	and too unreliable no matter how clean the tape heads are
		( too slow being the key problem for restoring )

c ya
alvin

> as expensive as IDE disks, not to mention the little matter of a 
> tape drive that costs as much as a server.  raid5 makes backup
> less about robustness than about archiving or rogue-rm-protection.
> I think the next step is primarily a software one - 
> some means of managing storage, versioning, archiving, etc...
> 

_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf