On 5/11/2010 9:40 AM, Sorin Srbu wrote:
>
> * The web-GUI is lightning fast! Which leads us to the discussion...
>
>
> I think the culprit was the software raid5-array the whole time... Peaking at
> approx 94-95% full pool since a few months back, the array was stretched
> nearly to the max for all intents and purposes. Although the syncing and
> checksumming of the raid5 array didn't seem to draw much power from the cpu's,
> it seems to have put quite a strain on the disk-subsystem. Raid5 hasn't been
> really recommended to use anyway, but I still wanted to try it out as it gave
> a redundancy of sorts. As it turns out, it works pretty good, but the pool
> can't be more than about 75-80% full, or the web-gui will have serious access
> time-problems. That is my conclusion at least.
>
> I'll let the raid0-array fill up and see if the access-problem will reoccur.
> Will report back in that case.

Read access is normally OK on a raid5.  The issues are that with a small 
number of drives you essentially force all the heads to seek together to 
handle writing the parity and on partial block writes you have to read 
first, then rewrite to update the parity.  So you slow down to the seek 
time of the slowest drive.  If you noticed speed issues even when 
backups were not writing to the array you probably had some other 
problem.  Did you check (cat /proc/mdstat) to make sure all the drives 
were working?  Perhaps it was running degraded and your eventual failure 
was when a 2nd drive dropped out.

-- 
   Les Mikesell
    lesmikesell AT gmail DOT com

------------------------------------------------------------------------------

_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/