At 04:42 AM 5/13/01 +0300, you wrote:
>Does suck_requeue queue the group at the end of the queue, or does it
>start sucking it again immediately?
It applies to non pull sucking, when the suck_batchsize/batchn limit
is hit it is added to the end of the sucking queue.
>I ask, because I had a disk failure the other day and lost about 200Gb -
>so my server's busy trying to catch up with a lot of old posts. I set
>suckn at 500 and suck_batchsize at 75000000 (I'm assuming that's bytes -
>so 75Mb - or have I misunderstood something?) to try to get it to go
>round all the cached groups catching up a little at a time but it seems
>to be spending an extraordinary time on individual groups (for example,
>alt.binaries.mp3 shows it's sucked 500Mb since I reloaded, about 5 hours
>ago)
As I said, pull true disables those two limits, as the pull module allows
concurrent sucking we didn't think the limit per group made sense. Obviously
it still does in this situation :-(
ChrisP.
>My 'parts' looks kinda odd too... I have a 10 gig parts bucket
>
> Ok Dup Rej Qued/Busy/Done MB/MAX Site
> 6890 32815 7 10/0/18 2363.44 west.usenetserver. *
>
>Parts 8796:507 3050mb, In 6701 2336mb, Complete 2756 1003mb, 41% 43%,
>Rej 0%
>Drop 1143mb, Err 0 Rotated 1274 minutes ago, Upto 91 0.29 125
>
>Dropped over a gig? I wonder why?? And what's with all the Dup's?
>
>It's late, I'm confused, I think I should leave it 'till morning and see
>how it's got on overnight...
If you suck old news without doing a rebuild_index first, then the history
index contains the old items, and it' won't re-fetch them, that may explain
some of the above, the duplicates and the large dropped value.
ChrisP.
