[nmglug] filesystem optimization on software raid 5

[Aaron]

Jason Schaefer wrote:
> Hi all
> 
> I am setting up a raid5 with 4 x 320gb drives. I am deciding what
> stride, block size, bytes per inode etc. This filesystem will store
> recordings that range from 50 to 2000mb, average of 350mb. It will also
> house a massive compressed audio library. Perhaps 30 thousand songs,
> average 3mb size each. I would like to optimize mostly for the larger
> files since they will be used in live production.
> 
> Thanks
> Jason
> 

RAID5, in general, is a bit dangerous.  Software RAID5, even more so.
As one disk dies, it tends to produce some bad data, which in turn,
corrupts the other drives.  Some data is often lost.
I'm not an expert at the recovery tools...  but theoretically,
you should only loose a little data if you can re-build the rest OK.

For reasons yet to be understood, I lost my RAID5 after only 2 months,
and the disks seemed OK.  (Jerks may have been unplugging the server,
though.  Some people do not respect UPS's)
I was able to force a re-build and recover the data, but I did have
to re-build the array, totally, to get rid of the 'unclean' complaints.
Again, if I knew RAID better, I may have been able to recover...
but I'm not that clever.



For a large raid (like 8-16 disks, not 4) I might go RAID6
(2 parts parity for every N parts data).
Right now, for smaller disk arrays, I would just LVM together as many
disks as I want, and if you want reliability, keep a rsync running
to another disk someplace.  (Like RAID1, but not as synchronized)
RAID1 is OK too, since I assume it is pretty easy to recover from
failures.  Disks are cheap now.  RAID1 makes sense.

Also...  It might make sense to go for 500GB drives now.
They are slightly more $/GB than 320's, but not much.
They will be the value leader very soon, so it might be good
to start out 1/2 step ahead of the technology curve.

                 aaron