john@wa3wbu.UUCP (John Gayman) (02/27/88)
I have been running News, patch-8 for many months. Yesterday I
patched up to #14, recompiled and replaced the old binaries. Everything
seemed to work. Old News was accessable, postnews worked, rnews did
it's thing, etc. I'm in fat-city, right ?
WRONG !!
I returned home from work tonight and find the hard disk thrashing
like crazy. It keeps looping on "sendbatch" to a site that theres no
News queued for. When I left for work the process numbers were at 1200,
9 hours later they're at 26000! This baby has been cranking while I
was away. ANyway, this dudes spawning sendbatch's faster than I can kill
them. I then do a "df", and guess what......all kinds of disk space
but ZERO inodes!!! Yep, the old "I ate all the inodes trick".
So I yanked out my backup tape of just before upgrading News (Thank
you God for letting me remember to backup) and restored everything to a
patch-level 8 state and its working smoothly again.
I remember reading other horror stories of sites upgrading past
8. Were there ever any fixes ? I mean, this happened within one day
and I've been running News "flawless" since last September. So I'm gonna
be real carefull before I try patch 14 again. The other thing is it
caused me to miss 500K worth of News. The news came in but it said it
couldnt exec compress because the News was garbled.
Has anyone else experienced these woes ?? I'd be *real* interested
in a fix or solution to the above scenerio.
Signed:
Disenchanted with patches
John :-)
--
John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john
1869 Valley Rd. | ARPA: wa3wbu!john@uunet.UU.NET
Marysville, PA 17053 | Packet: WA3WBU @ AK3P chris@lxn.UUCP (Christopher D. Orr) (03/04/88)
In article <504@wa3wbu.UUCP> john@wa3wbu.UUCP (John Gayman) writes: > > I have been running News, patch-8 for many months. Yesterday I >patched up to #14, recompiled and replaced the old binaries. Everything >seemed to work. Old News was accessable, postnews worked, rnews did >it's thing, etc. I'm in fat-city, right ? > > [ ... ] > > So I yanked out my backup tape of just before upgrading News (Thank >you God for letting me remember to backup) and restored everything to a >patch-level 8 state and its working smoothly again. > Actually yesterday I did just about the same thing. I patched my pathlevel 8 News software up to Patchlevel 14. I created a local test group to test out the posting, etc. Everything looked great up until I ran EXPIRE on these test messsages. Then the system went down! And I mean down. I had to cold boot the system to get anything working! After having to repair a number of disk partitions from the crash I've decided that pathlevel 8 gives me everything I need. What is the incentive to go to level 14 ???? Chris -- Christopher D. Orr | US MAIL: Alcyone Inc. UUCP: vu-vlsi\ | Lanark Building inhp4 - !lehi3b15!lxn!chris | Center Valley, PA 18034 c11ux / | Voice: (215) 282-4525
edm@nwnexus.UUCP (Ed Morin) (03/08/88)
I too have had problems with Patch level #14 of news. I'm running on a PDP 11/70 (no cracks please) and had fewer problems with patch level #8 than with #14. It's hard for me to be specific because memory limitations creep in quickly (even with split I/D space). (In fact, expire can't even rebuild the history file from a moderate amount of news!) Satisfied with level 8 (when my tape drive becomes function again), Ed Morin Northwest Nexus Inc. - Public Access Unix for the Masses edm@nwnexus.wa.us (soon)
mikel@codas.att.com (Mikel Manitius) (03/09/88)
In article <504@wa3wbu.UUCP>, john@wa3wbu.UUCP (John Gayman) writes:
-
- I have been running News, patch-8 for many months. Yesterday I
- patched up to #14, recompiled and replaced the old binaries. [ ... ]
-
- [ ... ] I then do a "df", and guess what......all kinds of disk space
- but ZERO inodes!!! Yep, the old "I ate all the inodes trick".
-
- So I yanked out my backup tape of just before upgrading News (Thank
- you God for letting me remember to backup) and restored everything [ ... ]
I generally make it a point not to make unfavorable comments about
people, but I really had a hard time keeping from laughing myself
out of the chair about this one!
This is a joke, right?
--
Mikel Manitius
mikel@codas.att.comdet@hawkmoon.MN.ORG (Derek E. Terveer) (03/09/88)
In article <253@lxn.UUCP>, chris@lxn.UUCP (Christopher D. Orr) writes: > [.. crash then cold iron boot..] > After having to repair a number of disk partitions from the crash I've decided > that pathlevel 8 gives me everything I need. What is the incentive to > go to level 14 ???? I was also running #8 on our vaxen at work for many, many, many moons with no problems (other than the persistent minor irritants) and was scared by the announcement that unless one upgraded to #14 all of the disk space would be eaten by the Supersedes: lines in comp.mail.maps, etc. So i got the patches from some friendly neighbor sites and upgraded. Other than really learning how to use patch, everything went smoothly. I have had no problems, except expire doesn't *always* seem to want to expire. No severe crashes. No crashes at all. It does make me wonder though, 'cause i keep seeing people complaining about the problems they are having and i have seen neither hide nor hair of these problems. I don't doubt they exist though. Perhaps its the upgrade somehow that kills and not the patches themselves. For example -- the vaxen that i upgraded from #8 to #14 were hardly fair tests since they got very little news and so weren't very well exercised. The machine that i'm writing on now (hawkmoon) had #14 installed on it (no previous News versions since its a new site) and i've have had nary a problem here as well. I can imagine that different expectations (of the software) between the patch levels could cause some problems. -- Derek Terveer det@hawkmoon.MN.ORG uunet!rosevax!elric!hawkmoon!det
james@bigtex.uucp (James Van Artsdalen) (03/10/88)
I've been running news patchlevel #14 since it came out on my 286 2.2, and now for the last week on my 386 2.2l, with no "lost" inodes. However, I have found that my slightly-modified inews must be compiled without the optimizer, or it produces a bad history file. I'm not going to try to track down the exact cause of the problem, as hopefully the new compiler from uPort is coming soon... On those inodes: Come on people, inodes don't just "disappear". If they're truly being lost by the kernel (highly unlikely), fsck will show it. If they're getting eaten by the /tmp locks (more likely), an "ls /tmp" will show it, and if the inodes are being consumed by .ina and other SPOOLDIR temporary files (most likely), "find SPOOLDIR -type f -name '.*' -print" will find them. -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
kls@ditka.UUCP (Karl Swartz) (03/11/88)
In article <3776@codas.att.com> mikel@codas.att.com (Mikel Manitius) writes: >In article <504@wa3wbu.UUCP>, john@wa3wbu.UUCP (John Gayman) writes: >- >- I have been running News, patch-8 for many months. Yesterday I >- patched up to #14, recompiled and replaced the old binaries. [ ... ] >- >- [ ... ] I then do a "df", and guess what......all kinds of disk space >- but ZERO inodes!!! Yep, the old "I ate all the inodes trick". (etc.) >I generally make it a point not to make unfavorable comments about >people, but I really had a hard time keeping from laughing myself >out of the chair about this one! > >This is a joke, right? >-- > Mikel Manitius > mikel@codas.att.com What do you find so funny about this posting, Mikel? John obviously had some problems with patch level 14. I'm inclined to believe his comments, as I've heard the same complaints from other sites. One of my newsfeeds refuses to go beyond path 8 for this very reason, and I've not been convinced to go beyond 8 myself. Too many horror stories. So tell us ... what's so funny about somebody having some problems with apparently buggy software? -- Karl Swartz |UUCP decvax!formtek!ditka!kls 1-412/937-4930 office | {floyd,pitt,psuvax1}!idis!formtek!ditka!kls |BIX kswartz "I never let my schooling get in the way of my education." (Twain)
mjy@sdti.UUCP (Michael J. Young) (03/11/88)
In article <914@bigtex.uucp> james@bigtex.UUCP (James Van Artsdalen) writes: >I've been running news patchlevel #14 since it came out on my 286 2.2, and >now for the last week on my 386 2.2l, with no "lost" inodes. However, I have >found that my slightly-modified inews must be compiled without the optimizer, >or it produces a bad history file. I'm not going to try to track down the >exact cause of the problem, as hopefully the new compiler from uPort is coming >soon... > >On those inodes: Come on people, inodes don't just "disappear". If they're >truly being lost by the kernel (highly unlikely), fsck will show it. And it does. This is a known problem that is common to all System V kernels, and has been discussed at length in comp.unix.questions (wizards?). Someone even posted a simple test that was guaranteed to cause the problem, as well as a fix for those who had a source license. The problem has to do with the way the kernel searches for free i-nodes, and has nothing to do with news. News just happens to be very effective at creating the situation in which the kernel bug appears. I've been running patch level #14, and I lose inodes, more frequently than I did under patch level #8. But I used to see them under level #8 also. I now run df and fsck on my spool volume every day just to be safe. I hope Microport was listening to the net when the original discussion was going on. I'd like to think that the next version of the kernel will incorporate the fix that was posted. How about it, Microport? -- Mike Young - Software Development Technologies, Inc., Sudbury MA 01776 UUCP : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy Internet : mjy%sdti.uucp@harvard.harvard.edu Tel: +1 617 443 5779
det@lily.UUCP (Derek Terveer) (03/12/88)
In article <253@lxn.UUCP>, chris@lxn.UUCP (Christopher D. Orr) writes: > [.. crash then cold iron boot..] > After having to repair a number of disk partitions from the crash I've decided > that pathlevel 8 gives me everything I need. What is the incentive to > go to level 14 ???? I was also running #8 on our vaxen at work for many, many, many moons with no problems (other than the persistent minor irritants) and was scared by the announcement that unless one upgraded to #14 all of the disk space would be eaten by the Supersedes: lines in comp.mail.maps, etc. So i got the patches from some friendly neighbor sites and upgraded. Other than really learning how to use patch, everything went smoothly. I have had no problems, except expire doesn't *always* seem to want to expire. No severe crashes. No crashes at all. It does make me wonder though, 'cause i keep seeing people complaining about the problems they are having and i have seen neither hide nor hair of these problems. I don't doubt they exist though. Perhaps its the upgrade somehow that kills and not the patches themselves. For example -- the vaxen that i upgraded from #8 to #14 were hardly fair tests since they got very little news and so weren't very well exercised. The machine that i'm writing on now (hawkmoon) had #14 installed on it (no previous News versions since its a new site) and i've have had nary a problem here as well. I can imagine that different expectations (of the software) between the patch levels could cause some problems. -- Derek Terveer det@hawkmoon.MN.ORG uunet!rosevax!elric!hawkmoon!det -- Derek Terveer det@hawkmoon.MN.ORG ..!uunet!rosevax!elric!hawkmoon!det
wcs@ho95e.ATT.COM (Bill.Stewart.<ho95c>) (03/12/88)
In article <914@bigtex.uucp> james@bigtex.UUCP (James Van Artsdalen) writes:
:On those inodes: Come on people, inodes don't just "disappear". If they're
:truly being lost by the kernel (highly unlikely), fsck will show it.
Well, they do, and it's the kernel's fault, and fsck does find
them again. There's an obscure System V bug that was
reported in the news.admin groups a few months back, which
causes the superblock to think there are zero inodes left.
It mainly happens when you're shlepping around a lot of inodes at
once, which is to say it "only" affects netnews.
On my machine, /usr/spool has its own file system; if it loses
all the inodes (rare, but it's happened twice in the last 6 months),
I can kill cron and lp, and umount/fsck/remount the file
system, without taking the machine down. It's annoying, but
better than kicking everyone off.
Aside from the inode bug, there's also the fact that news just
*needs* a lot of inodes. (I'm using double the default number.)
I've also found it helps to keep $LIBDIR and $SPOOLDIR on
separate file systems; if they're on the same system and it
fills up, expire can't run.
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
# So we got out our parsers and debuggers and lexical analyzers and various
# implements of destruction and went off to clean up the tty driver...zeeff@b-tech.UUCP (Jon Zeeff) (03/13/88)
In article <914@bigtex.uucp> james@bigtex.UUCP (James Van Artsdalen) writes: > >On those inodes: Come on people, inodes don't just "disappear". If they're There is a bug in most Sys V kernels that does this. It's happened to me a few times and to many others. A fsck -S cures it. It fairly rare. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
rees@apollo.uucp (Jim Rees) (03/15/88)
Aside from the inode bug, there's also the fact that news just *needs* a lot of inodes. (I'm using double the default number.) If you had an Apollo with the Domain/OS file system, you wouldn't have this problem. If it runs out of inodes, it just allocates more out of the free list. This shouldn't be too hard to hack into your kernel, too.
geoff@desint.UUCP (Geoff Kuenning) (03/16/88)
In article <3adab345.b8ab@apollo.uucp> rees@apollo.uucp (Jim Rees) writes: > Aside from the inode bug, there's also the fact that news just > *needs* a lot of inodes. (I'm using double the default number.) > > If you had an Apollo with the Domain/OS file system, you wouldn't have > this problem. If it runs out of inodes, it just allocates more out > of the free list. This shouldn't be too hard to hack into your kernel, > too. This is not impossible on System V, but you can't just grab them from the free list. The kernel assumes (for speed) that the inode list is contiguous. So you'd have to grab the first block or blocks immediately following the i-list. Assuming it was occupied by something useful (originally, it would be the root directory) you'd then have to grab a block off the free list and relocate the grabbed block there. Then you'd have to locate whichever i-node or indirect block pointed at it, and redirect to reflect the relocation. (Got that?) The code isn't actually very complicated, but the kernel would have to shut down the affected filesystem for the duration, and on a large filesystem the search for the guilty indirect block would take quite a while. Fortunately, I've forgotten most of the details of the BSD not-so-fast filesystem, so I can't comment on whether BSD could implement something like this. (Besides, this is soooo un-Unix-like. Next you'll be wanting to expand kernel tables as necessary, or even swap space. Whatcha want, a 20th-century operating system? Egad! :-) -- Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
page@swan.ulowell.edu (Bob Page) (03/17/88)
rees@apollo.uucp (Jim Rees) wrote:
>If you had an Apollo with the Domain/OS file system, you wouldn't have
Apollo doesn't ship Domain/OS. Let's talk about real file systems.
..Bob
--
Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
"Why? It's the heat." -- Laurie Andersonroot@uwspan.UUCP (John Plocher) (03/17/88)
+---- mjy@sdti.UUCP (0000-Michael J. Young) writes in <245@sdti.UUCP> ---- | I hope Microport was listening to the net when the original discussion was | going on. I'd like to think that the next version of the kernel will | incorporate the fix that was posted. How about it, Microport? +---- They *should* have it -- I emailed it to them when it was first posted! -John -- Comp.Unix.Microport is now unmoderated! Use at your own risk :-)
wes@wsccs.UUCP (Barnacle Wes) (03/23/88)
In article <569@lily.UUCP>, det@lily.UUCP (Derek Terveer) writes: > I was also running #8 on our vaxen at work for many, many, many moons with no > > I have had no problems, except expire doesn't *always* seem to want to expire. [...cajoled/threatened into upgrading to patchlevel 14...] > No severe crashes. No crashes at all. It does make me wonder though, 'cause > I keep seeing people complaining about the problems they are having and i have > seen neither hide nor hair of these problems. Are you running System V or a Berzerkley derivative on your VAX? The problem with i-nodes dissappearing seems to be a SysV-ism, buried in the kernel. Wes Peters -- /\ - " Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes
det@hawkmoon.MN.ORG (Derek E. Terveer) (03/31/88)
In article <359@wsccs.UUCP>, wes@wsccs.UUCP (Barnacle Wes) writes: > Are you running System V or a Berzerkley derivative on your VAX? I running at&t sysV r2.0. sigh -- it would be nice to have a little later version... -- Derek Terveer det@hawkmoon.MN.ORG uunet!rosevax!elric!hawkmoon!det