for each disk in a raid5, large file write rate will increase while small
file write rate will decrease. the solution is not necessarily having a
smaller stripe size as many of the files will still be smaller than a 64k
stripe so that is a minor improvement that may not compensate for the
slowdown on large files that benefit from large stripe size.
It may be worth considering NOT using raid5 at all. use raid1 and get some
1TB drives and add more servers when that 1TB is no longer sufficient OR
replace those drives with larger drives in the future. raid0 does not incur
the parity penalty and can be done in software without a performance hit. a
single drive or a raid1 mirror will perform quite well as there will be not
sync issues, nor hard link issues AND less drives=less chance of failure.
with 3 drives in a raid5, you can lose 1/3 of the drives and still keep data
but you are 3x more likely to lose a drive. in raid 0, you are 1/2 as
likely to lose a data drive because losing a disk is not losing a data
drive, just a backup. in other words, with raid5 you can only afford to
lose 1-(xDrives-1:xDrives) or 1/3 in a 3 disk array while raid0 allows you
to lose 50% of the drives..
also consider that drives purchased together are likely to fail within a
close timeframes as they all have the same MTBF. replacing a backup drive
with a larger drive before the MTBF is reached is a good policy and is quite
logical for growing backup storage needs.
open source software on consumer grade hardware has traditionally been very
efficient and very cost effective, no reason that senario should be any
different with backuppc. more, smaller servers is a good thing.
On Mon, Mar 3, 2008 at 8:01 PM, David Rees <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 3, 2008 at 6:47 PM, Adam Goryachev
> <[EMAIL PROTECTED]> wrote:
> > So would it then make sense for a backuppc data partition to use a
> > smaller stripe size since most writes will be very small?
>
> Yes, if you're using RAID5. Doing some benchmarking would help find
> the "sweet spot".
>
> > > Having battery backed RAM on the RAID controller can help, because
> the
> > > controller can lie to the OS and say the data is written to disk
> > > immediately instead of waiting for an read-calculate-write cycle,
> > > since it's sure that if it does lose power, it can store the data
> that
> > > should be written to disk later when power is restored in addition to
> > > buffering the reads/writes so that it can reorder them to reduce the
> > > amount of seeking required.
> >
> > Is it possible to instruct linux to use it's memory to do this? If you
> > have a UPS and feel that it is pretty unlikely to crash, you might be
> > happy to get this kind of speed improvement.
>
> Yes, it's possible to tune Linux to do this as well. To get some
> ideas, look at the "large archives and scalability issues" thread,
> this exact subject just came up in the past couple days. Be warned,
> the thread is very long.
>
> -Dave
>
> -------------------------------------------------------------------------
> 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
> [email protected]
> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki: http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
-------------------------------------------------------------------------
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
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
