building a RAID system - yup
alvin at Mail.Linux-Consulting.com
Wed Oct 8 22:33:49 EDT 2003
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.
> > - 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 )
> 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
More information about the Beowulf