----- Original Message ----- From: "Mike S. Lacanilao" <[EMAIL PROTECTED]> To: "Philippine Linux Users Group Mailing List" <[EMAIL PROTECTED]> Sent: Tuesday, February 10, 2004 12:02 PM Subject: Re: [plug] software RAID5 vs. single large HD
> plug bert wrote: > > >Hi All! > hi! > > >Would a software raid5 setup be a wise alternative? My > >primary concern is to make sure the server isn't > >bogged down by heavy disk i/o > > > > we are using raid5 here in our productions, i can say that this thing > really helps us to prevent data corruption due to power down/system > crash, it just allowing you to have more disks to access in just one > single logical drive, so the input is going to be faster than in single hd. any raid technologies cannot prevent you from data corruption... raid 0+1, 1 and 5 will provide you resiliency in case of disk failure but not data corruption... a corrupt data written to these raid numbers will remain corrupt... > the thing is "software" raid5 is not sufficient, try hardware raid, > gagastos ka nga lang.. software raid and hardware raid have the same functionalities... the difference is that hardware raid have its own cpu (for processing), ram (for buffering) and internal batteries (for flushing the buffer cache properly in case of power failure) while the software raid entirely depends on your server's cpu and ram to spare.... plug bert, since you are worrying about heavy disk i/o activity.. take note that raid 5 is faster for reading but slower for writing due to addtional parity writes... if your application is more on read i/o, then raid 5 is already good for you... other factors to consider for better disk i/o performance aside from using raid: 1. disk performance (eg. transfer rate, seek time, buffering, etc) 2. disk controller bandwidth (the higher the better) 3. ram for disk buffering (the higher allocated for buffering the better to prevent disk i/o blocking) 4. filesystem (try to benchmark different filesystems) 5. block size, fragment size, etc for a filesystem (different applications require different block sizes) 6. seconds to flush or write for file, directory and metadata delay 7. if more disks to use... try to consider using scsi or similar technologies like serial ata, etc... 8. and others that i cant think as of the moment.... it is worth noting also that putting your data on the outer tracks is much faster than on the inner tracks of a disk... fooler. -- Philippine Linux Users' Group (PLUG) Mailing List [EMAIL PROTECTED] (#PLUG @ irc.free.net.ph) Official Website: http://plug.linux.org.ph Searchable Archives: http://marc.free.net.ph . To leave, go to http://lists.q-linux.com/mailman/listinfo/plug . Are you a Linux newbie? To join the newbie list, go to http://lists.q-linux.com/mailman/listinfo/ph-linux-newbie
