msb@sq.sq.com (Mark Brader) (04/30/91)
Geoff Collyer (geoff@world.std.com) writes: > A change that just missed the last patch and should be in the next one is > that inews will (finally) invoke newsspool or rnews instead of relaynews... I certainly hope *not*. At sq, we have /usr/spool/news/in.coming configured to be on a separate filesystem from /usr/spool/news. In.coming is on a filesystem used for other purposes, but from which news can "borrow" large amounts of space for, say, a period of a few days; /usr/spool/news is dedicated to news. By doing this, we can run /usr/spool/news *much* closer to the safety threshold than would otherwise be tolerable, and thus run with considerably longer expiry times than otherwise possible. I can't imagine anyone who values their news feed doing it any other way -- well, not unless either (a) they have so much disk space that expiry is not an issue, (b) they have so *little* disk space that they can't spare any more for in.coming, or (c) political or technical reasons prevent it. (Digression: one possible technical reason is that, unless it's changed since I last looked, C News has no configuration option to split the filesystems this way; so one either has to use symbolic links, which not everybody has, or one has to do a lot of local patching.) Since we adopted this configuration we have *never* lost news due to filesystem overflows, even when upstream glitches have held things up so badly that, when the logjams broke, we would get 2-3 times the regular volume for 2-3 days running. But what this means is that, when such an event happens, sometimes we have news sitting in in.coming for longer periods than usual, occasionally even longer than 2 days. It is not tolerable that, when this happens, locally originated postings should be held up for that length of time. (Among other reasons is that we use news internally as our corporate "bulletin board".) In recent releases of C News, inews has checked whether /usr/spool/news was full to the safety threshold before allowing even a local posting; we have had to disable this. If inews is now to be changed to throw the local postings in with all the delayed batches in in.coming, it will be a much greater inconvenience. Geoff and Henry, please do not ruin the successful news configuration that we have arrived at. -- Mark Brader "Bad news disturbs his game; so does good; SoftQuad Inc., Toronto so also does the absence of news." utzoo!sq!msb, msb@sq.com -- Stephen Leacock This article is in the public domain.
adeboer@gjetor.geac.COM (Anthony DeBoer) (04/30/91)
In article <1991Apr29.202116.21681@sq.sq.com> msb@sq.sq.com (Mark Brader) writes: >Geoff Collyer (geoff@world.std.com) writes: >> A change that just missed the last patch and should be in the next one is >> that inews will (finally) invoke newsspool or rnews instead of relaynews... > > [...] >But what this means is that, when such an event happens, sometimes we >have news sitting in in.coming for longer periods than usual, occasionally >even longer than 2 days. It is not tolerable that, when this happens, >locally originated postings should be held up for that length of time. >(Among other reasons is that we use news internally as our corporate >"bulletin board".) > >In recent releases of C News, inews has checked whether /usr/spool/news >was full to the safety threshold before allowing even a local posting; >we have had to disable this. If inews is now to be changed to throw the >local postings in with all the delayed batches in in.coming, it will be >a much greater inconvenience. Geoff and Henry, please do not ruin the >successful news configuration that we have arrived at. I partially second that. The proposed change does mean that when "spacefor articles" is up against the wall, it won't dump a posting in dead.article for the user to try again with later. It'll accept it and post it when it's able to. That much is good. (But what will this change do when "spacefor incoming" is low?) There is the possibility of delaying articles. I have newsrun wake up and check in.coming every 10 minutes (we ran into a problem that my upstream feed could send me a batch, spool up some more news, and send that to me, a few times before newsrun woke up). Also, I'm not turning newsrunning off during the day. The delay before a spooled local article showed up wouldn't be a problem under those circumstances, but of course these aren't the defaults. I'd like to see some way of prioritizing local postings (perhaps by having newsrun sort batches by size and unbatch the smallest ones first?). That way, if "spacefor articles" is low, local articles would tend to get posted ahead of batches from the net. (This could also help allow for propagating local news on multiple local machines). Also, if perhaps this could be extended to a change to the "newsrunning" mechanism, to set a maximum batch size for daytime running, this could allow for people who turn news off during working hours (ie. "newsrunning 10000" would limit unbatching to batches not exceeding 10000 bytes. "Off" would be equivalent to "0", and "on" would mean no limit). I guess the key difference is that Mark B. prefers to let a backlog build up in in.coming, while I like to see in.coming keep flowing. In order to get "local batches", you'd need to maintain at least a minimal flow, so that little batches get run while it holds up big batches. [A low-space-sensitive article-dumper (let's not call it an "expire", since it doesn't do everything C-News expire does nightly) might help here, to effectively automate the process of me typing "df", saying something rude, su'ing, cd'ing /usr/spool/news/alt/whatever, and rm'ming 100 or so of the oldest articles. Something like that could really help even out some of the net.sunspots or whatever it is that causes news surges.] A minor related quibble is that spacefor should be capable of checking inode availability, since that's what you run out of first in /usr/spool/news often enough. Anyway, I hope these ideas aren't completely silly and I haven't trodden on anyone's toes. flames | mail. -- Anthony DeBoer NAUI#Z8800 | adeboer@gjetor.geac.com | Programmer (n): One who Geac J&E Systems Ltd. | uunet!geac!gjetor!adeboer | makes the lies the Toronto, Ontario, Canada | #include <disclaimer.h> | salesman told come true.
brad@looking.on.ca (Brad Templeton) (05/01/91)
Just modify newsrun to handle two queues, with different space critiera. The local queue and the remote queue. You can even run one during the day and the other not. Spooling of locals is more efficient. In fact, it would be even more so if you could get relaynews to handle all the articles in the local queue in one go with "relaynews *." One relaynews per spooled local article isn't all that much of a saving. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
henry@zoo.toronto.edu (Henry Spencer) (05/01/91)
In article <1991Apr30.211819.20285@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >Just modify newsrun to handle two queues, with different space critiera. Actually there *is* a priority-queueing facility in the current newsrun, although nothing uses it yet. -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry