Xref: utzoo news.admin:14565 comp.mail.uucp:6650 Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!lsuc!eci386!ecicrl!clewis From: clewis@ferret.ocunix.on.ca (Chris Lewis) Newsgroups: news.admin,comp.mail.uucp Subject: Re: BITFTP Message-ID: <1527@ecicrl.ocunix.on.ca> Date: 21 May 91 21:59:49 GMT References: <1991May16.161706.2680@jarvis.csri.toronto.edu> <103410@becker.UUCP> Followup-To: news.admin Organization: Elegant Communications Inc., Ottawa, Canada Lines: 70 In article <103410@becker.UUCP> bdb@becker.UUCP (Bruce D. Becker) writes: >In article stanley@phoenix.com (John Stanley) writes: >|[...] >| Like I said. The problem was not BITFTP. The problem is software >|that happily attempts to scribble across a disk on which there is no >|space. We would not accept this in any other application, especially an >|unattended one, but we will accept this from uucico. > I use a program which monitors spools space & > inodes, and shuts off uucico or uuxqt if the > level goes too low. It uses a shell script as > part of its structure so that it can be invoked > with different parameters depending on the login > name or the system name, whichever is appropriate > in the given context. > Used carefully, it provides a kind of large- > granularity type of flow control with respect > to news and email throughput, which seems more > useful than C news' approach of throwing away > incoming stuff if there isn't room. Lsuc has one of these too. When I was last working on it (it may have been worked on since), I made a concious decision to not simply shut off uucico completely when the disk space went below the thresholds. Instead, "spoolfull" disables (and kills if necessary) uucicos that are likely to be bringing *in* lots of stuff. Ie: the incoming main feed (attcan) and a couple of other sites (utzoo being one. Becker was for a while - may still be, can't remember whether I disabled that). When the diskspace becomes available again, it automatically reenables uucico. The idea being that other sites (particularly outgoing news feeds) should remain enabled because they are taking stuff *off* lsuc, and if I disabled all uucico's, then it might never turn itself back on, and everything would stall out indefinately. (Jim was new to news at the time, and Dave wasn't doing it anymore, so I thought it should be as automatic as possible). (There are other issues, such as uucp between internal lsuc machines, and ordinary mail that made turning uucico completely off impractical) This can't be done entirely within uucico, because there are other disk partitions (ie: news) to take into account - spoolfull can do that, but it's REAL HARD for something like spoolfull to figger out *who* is shovelling stuff in to be precise in who to shut off. With spoolfull, and some careful c-news tuning lsuc has been remarkably robust in the face of 20Mb+ news surges from its feeds. On the other hand, static decisions such as the ones I made won't work in the face of dorks who insist on imposing their 50MB VMS utility downloads on all and sundry. It's been said before, and I'll say it again: lsuc has been remarkably generous in its disk, line, cpu and human resources over the years (I think I gave it its first feed in '84). And over these years it has been remarkably reliable (especially when you consider what their machine was for the first 5 or so years!). Lsuc and its administrators deserve nothing but praise for doing a good job over a long period of time. No machine has infinite resources, especially ones that don't charge for their services (such as lsuc). People using them, even indirectly, shouldn't abuse it. People who scream and yell that sites that can't handle mail surges shouldn't be in the mail forwarding business should consider two things: 1) There wouldn't be a net AT ALL if every site took that attitude 2) You should try running a site with 50+ mail feeds, and 10+ news feeds for a while. -- Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!