first thing first. get your drives down to ~%80 usage! degragging the
drives is useless unless you make some room.
second, reiserfs sounds like a great filesystem, but in practice it is not
very good at long term performance and reliability. i have worked with
filesystems on many many systems and reiserfs should still be beta(any
version) and with Hans legal issues i doubt it has a future.
so. i would suggest you move off of reiserfs on that drive. move to xfs or
ext3. get the disk usage down and defrag those drives. even the best
filesystems cant keep from getting fragmented if they are full unless they
reserve blocks, which takes space, so same outcome in the end, you need more
free space.
from your graph, you have lots of IO wait, which is most likely caused by
the full, fragmented disks. also, your drive benchmarks will be slower than
they should because you are wrighting to the inside of the disk which is
much slower.
On 10/25/07, Hendrik Friedel <[EMAIL PROTECTED]> wrote:
>
> Hi David,
>
> > On 10/24/07, Hendrik Friedel <[EMAIL PROTECTED]> wrote:
> > > Well, what surprises me is, that I can't hear it seeking...
> >
> > Try using `iostat 3` or similar during a backup. Typical 7200
> > rpm IDE disks can't do more than 100-150 IOP/s or so.
>
> See the attached file.
> You'll find the information iostat 3 gives.
> I averaged 20 lines for 20 points in the diagram. I.e. there are the same
> number of points (roughly 9000) in the diagram, each representing the
> average of 20.
> I don't know how to interpret the graphs, though.
>
> > > /dev/hda5 94% /mnt/data <--xfs, not used by backuppc
> > > /dev/hdb1 99% /mnt/data1 <--reiserfs, backuppc
> >
> > Eek! Keeping your disks over 90% full is a bad idea. I really
> > suspect that your reiserfs partition is very heavily
> > fragmented. I must wonder if the directory structures have
> > also become fragmented. At least with xfs you can degragment
> > it online.
>
> I defragmented hda. It's at 2% now.
>
> > > > You should also check that each disk is running full speed by
> > > > running hdparm -tT /dev/hdX. You should be seeing at
> > least 30MB/s,
> > > > probably
> > > > 40-50MB+.
>
> Now, in Idle it is:
> /dev/hda:
> Timing cached reads: 306 MB in 2.00 seconds = 152.87 MB/sec
> Timing buffered disk reads: 52 MB in 3.09 seconds = 16.84 MB/sec
> /dev/hdb:
> Timing cached reads: 264 MB in 2.01 seconds = 131.60 MB/sec
> Timing buffered disk reads: 110 MB in 3.01 seconds = 36.50 MB/sec
> vdr01 ~ # hdparm -tT /dev/hda
>
> But I assume, hda was not really idle (it's the system disk...). The worst
> result was even 5MB/s for hda. But still, the pool ist on hdb.
>
> Greetings,
> Hendrik
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> 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/
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
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/
