Adam Goryachev wrote:
>
> If you are writing small files and doing directory operations you
>> are back to waiting for the heads to seek.
> But since you have more heads, do you still have to wait for all of
> them, or is the one that you want to move more likely to be available
> to go and fetch the data you want?
When you are writing, you pretty much have to wait, because you have to
read the current data, merge your change, recompute parity, write
parity, write data.
> Consider the difference with 3 x 500G drives and 5 x 250G drives. If
> both are in RAID5 then you will get 1TB storage space. To do any
> operation on the 5 x 250 drives, would it not be more likely that the
> bit of data you want to read (or write) is on a drive whose heads are
> not already busy doing something else?
Reading, yes - writing you'll wait for the parity drive to seek even if
you got lucky on the data.
> I don't think it would be such a great idea, but if you extrapolated
> this to using say 20 x 120G drives, would that improve things further?
> (I wouldn't like to do it, because the chance of losing 2 drives from
> 20 would be greater than losing 2 from 5)
>
> PS, I seem to recall there is an upper limit to the number of drives
> in a RAID5 of 7 or 8, so the above is probably not possible.
>
> Also, since backuppc seems to read a lot more data than it writes
> during a backup, would it be fair to suggest that it is better to use
> RAID1 rather than RAID5 ?
>
> Or even RAID 1 + 0... you could get 3TB usable space with 6 x 1TB disks...
RAID1 or variations will always be better, but at some expense in disk
space. But, you can get by with software raid1 without too much
overhead where you'd probably want hardware for raid5 so cost wise it
will depend on the total size of the array.
--
Les Mikesell
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
