Maybe I am missing something here, but do I need to have the estimates? Does something depend on this? If I just ripped this out somehow (no idea how I would go about doing this) then waiting 7 hours for an estimate would no longer be a problem... right?On Wed, 21 Jul 2004 at 12:00am, Stefan G. Weichinger wrote > Hi, Kris, > > on Dienstag, 20. Juli 2004 at 23:14 you wrote to amanda-users: > > KV> The box is running redhat 9 with 2.4.20 kernel and ext3 filesystem. > KV> Below is the most recent sendsize.debug > > KV> sendsize[27747]: time 11114.784: Total bytes written: 429923983360 (400GB, 37MB/s) > > ok ... > > KV> sendsize[27747]: time 18815.342: Total bytes written: 69237104640 (64GB, 8.6MB/s) > > not ok --- Actually, both of those are *very* slow. Remember, those are estimates, and they "write" to /dev/null. When tar does that, it doesn't actually read the bits off the spindles, it just stats the files. On my big (Linux) file servers, I get estimate rates on the order or GB/s -- up to 80GB/s in some cases. One difference, though, is that I'm using XFS.
I am using a 3ware 12 port RAID card. Initially when I set the card up I did some benchmarking and the read/write speeds to the drives being backed up were excellent, what they were doesn't come to mind at this moment. I am trying not to take this machine down for any reason as it is a HUGE hassle, but it looks like I am going to have to.> I would: > > - split venus:/home into several DLEs (via exclude/include) I don't know that this will help. > - exclude unnecessary subdirs/files (./qa/build-main-branch-rfexamples/rfexamples-20040719/customer_test/Nestoras4/Freq > Domain/Linux_temp-g seems like a candidate to me) That's a good idea, of course. > This would spawn several sendsize-processes in parallel ... Actually, if you look at sendsize*debug, the estimates occur sequentially, not in parallel. ICBW, but that's how it looks to me. Kris, I think that you need to some performance testing/optimizing of your system. What controllers are you using?
I tried using noatime for the run last night and that didn't seem to help worth squat.Have you tested with bonnie++ and/or tiobench? Are there mount parameters to ext3 you can play with (data="" comes to mind)?
I am using redhat's kernel 2.4.20-20.9smpYou may also want to spend some time on bugzilla and see if there's some other kernel-foo you can apply to RH's kernel (I assume you're using RH's kernel -- if not vanilla 2.4.20 is awfully old...) to speed up disk stuff.
<<attachment: smiley-6.png>>