JWSmythe wrote:
>
> The difference between theory and real world performance are always a
> lot of fun.
The difference between theory and practice is that in theory there isn't
any difference...
> RAID5 does striping and parity, so it could, should, and might be faster.
For reads - and per
The difference between theory and real world performance are always a
lot of fun.
RAID5 does striping and parity, so it could, should, and might be faster.
A lot of it has to do with the drives, the controller, and even the
OS. I went around with this with several people over the years,
That assumption is generally true especially for larger files. for small
files, the whole array is dependant on the slowest drive in the array so the
access time is slowest drive - controller overhead - parity penalty whcih
means that in all circumstances, a file that is less than the stripe size
Carl Wilhelm Soderstrom wrote:
> On 03/03 02:29 , Les Mikesell wrote:
>
>> The seek time for these may be the real killer since you drag the parity
>> drive's head along for the ride.
>>
> The more drives you have in an array, the closer your seek time will tend to
> approach worst-case, a
Re RAID5 vs RAID6 vs other things.
I did a study a little while ago on such things comparing Areca and
3ware hardware RAID cards for a storage brick, mainly to compare the
performance correlates of Linux filesystems, # of spindles, and
other parameters. To my surprise, I found very little di
Im sorry, I did mean raid1 mirror, not raid0 stripping.
On Tue, Mar 4, 2008 at 2:40 AM, Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
> dan schrieb:
>
> > 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 a
David Rees schrieb:
> On Mon, Mar 3, 2008 at 5:01 PM, Christopher Derr <[EMAIL PROTECTED]> wrote:
>> Is backuppc up to the task of backing up TBs of data? Or should I be
>> looking at software that explicitly states "for the enterprise" like
>> Symantec Backup Exec, Legato, or even open source
dan schrieb:
> 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 c
Adam Goryachev schrieb:
>> 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
Adam Goryachev schrieb:
(...)
> Recently some optimisations were discussed that made a significant
> difference:
> 1) Mount your filesystem with noatime or equivalent so every time
> backuppc looks at a file it doesn't need to write the new atime. The
> atime is not relevant to backuppc anyway. Y
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 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".
> > H
Christopher Derr wrote:
>
>>
> Right. The reason I mention a multiple-head/SAN situation is that
> people were recommending more than one backuppc server. If that's a
> memory/cpu issue, then multiple-heads would help. If it's a
> disk-thrashing issue, nothing is really going to help other th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Rees wrote:
> On Mon, Mar 3, 2008 at 12:08 PM, Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
>> RAID5/6 have a performance penalty when compared to other RAID level
>> because every single write (or, write IO operation) requires four disk
>> I
On Mon, Mar 3, 2008 at 5:01 PM, Christopher Derr <[EMAIL PROTECTED]> wrote:
> Is backuppc up to the task of backing up TBs of data? Or should I be
> looking at software that explicitly states "for the enterprise" like
> Symantec Backup Exec, Legato, or even open source Bacula? All of these
>
On Mon, Mar 3, 2008 at 2:54 PM, Adam Goryachev
<[EMAIL PROTECTED]> wrote:
> I was always led to believe that the more drives you had in an array the
> faster it would get. ie, comparing the same HDD and controller, if you
> have 3 HDD in a RAiD5 it would be slower than 6 HDD in a RAID5.
For mos
On Mon, Mar 3, 2008 at 12:08 PM, Tomasz Chmielewski <[EMAIL PROTECTED]> wrote:
> RAID5/6 have a performance penalty when compared to other RAID level
> because every single write (or, write IO operation) requires four disk
> IOs on two drives (two reads, and two writes), possibly harming other I
>> Alternatively, I could go the more extensible route: multiple,
>> slightly less buff memory-wise backuppc servers, backing up to a
>> large SAN, even at the same time. For an environment where I may be
>> backing up data in the terabytes, would multiple backuppc head nodes
>> backing up t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Les Mikesell wrote:
> Christopher Derr wrote:
>> Alternatively, I could go the more extensible route: multiple, slightly
>> less buff memory-wise backuppc servers, backing up to a large SAN, even
>> at the same time. For an environment where I may
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
Christopher Derr wrote:
>
> So I can see it both ways I guess. I can back up 500 GB at a time from
> a 2 TB server for example, making good use of my 8 GB of memory for each
> full backup (4 full backups per week to get the entire 2 TB). This is
> if I have one backuppc server with onboard d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Les Mikesell 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 like
"> just take Les' advice, split up the backup job among a few servers
instead of one BIG one.
I guess he meant splitting one big backup job into several smaller
(i.e., instead of backing up 1x350 GB, backup 7x50 GB, all that to one
BackupPC server) - it is always a good idea for large backups."
Adam Goryachev wrote:
>>
>>> The seek time for these may be the real killer since you drag the parity
>>> drive's head along for the ride.
>>>
>> The more drives you have in an array, the closer your seek time will tend to
>> approach worst-case, as the controller waits for the drive with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carl Wilhelm Soderstrom wrote:
> On 03/03 02:29 , Les Mikesell wrote:
>
>> The seek time for these may be the real killer since you drag the parity
>> drive's head along for the ride.
>>
> The more drives you have in an array, the closer your
On 03/03 02:29 , Les Mikesell wrote:
> > CPU load because of RAID5/6 computations on today hardware is marginal.
> > RAID5/6 have a performance penalty when compared to other RAID level
> > because every single write (or, write IO operation) requires four disk
> > IOs on two drives (two reads, an
Tomasz Chmielewski wrote:
>>
>> with 8GB of ram, I would give a rough estimate that you can have up to
>> 500,000,000 files in flight at one time as far as ram is concerned!
>> that includes ALL hosts that would be backed up simultaniously. I doubt
>> RAM will be an issue for you. Probably ha
dan schrieb:
> amen Les
> no need to have just 1 backup server!
>
> with 8GB of ram, I would give a rough estimate that you can have up to
> 500,000,000 files in flight at one time as far as ram is concerned!
> that includes ALL hosts that would be backed up simultaniously. I doubt
> RAM will
amen Les
no need to have just 1 backup server!
with 8GB of ram, I would give a rough estimate that you can have up to
500,000,000 files in flight at one time as far as ram is concerned! that
includes ALL hosts that would be backed up simultaniously. I doubt RAM will
be an issue for you. Probabl
Christopher Derr wrote:
>
> I'm a new backuppc user for a college academic department. I have a
> moderately sized disk array (3 TB, RAID 5, Areca RAID) backing up the
> data on various servers.
I think that's the first time I've heard someone call 3 TB "moderately
sized", but I guess times
Greetings,
I'm a new backuppc user for a college academic department. I have a
moderately sized disk array (3 TB, RAID 5, Areca RAID) backing up the
data on various servers. The backup server has 8 GB of memory and is
currently running a backup of 350 GB user directories on a Windows 2003
se
31 matches
Mail list logo
