Xref: utzoo news.admin:3392 news.software.b:1621 news.sysadmin:955 comp.unix.questions:9232 Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!haven!umbc3!mbph!hybl From: hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) Newsgroups: news.admin,news.software.b,news.sysadmin,comp.unix.questions Subject: Alzheimer's Syndrome Keywords: Lost_inodes Message-ID: <576@mbph.UUCP> Date: 15 Sep 88 22:55:34 GMT Organization: University of Maryland, School of Medicine, Baltimore, MD 21201 Lines: 76 Mbph is using news_version "B 2.11 12/1/87" at patch_level 14; it is a leaf node from umbc3. Mbph is an AT&T 3B2/400 computer runing version 3.0 release 2 UNIX. It has two 72MB hard disks partitioned into file systems /, /usr, /usr2, /usr3 and /usr4. Mbph receives compressed news batches twice a day. Expire is run late each evening about an hour before polling our feed. We do not take a full feed; only comp, news, sci, bionet and a few other small groups. The news is retained 7 days. Everything seemed to be runing properly until one morning the following was scrolled on the screen of the console terminal: "Notice: Out of inodes on integral hard disk 1, partition 10." A df command showed that this was /usr4 and that there was only 1 inode available. It also showed that there were about 30000 blocks of disk memory available; each block can hold 1024 bytes. /usr4 is dedicated to the spool containing directories for the news groups. (The batched news segments are received by /usr/spool/uucp/umbc3.) /usr4 can hold a total of 49572 blocks and 6217 inodes. The du -a /usr4 | wc commands showed that slightly more that 3000 inodes were actually being used. The /usr4 file system was showing symptoms of Alzheimer's disease:-) I used the fsck command to cure the problem. Unfortunately, it was short lived--the patient has suffered at least two relapses. I have followed some of the activities during the transfer and processing of news batches. While the communication link is active as shown by using the uustat -q command, directory /usr/spool/uucp/umbc3 is slowly growing by adding X.* and D.* files while file TM.* is receiving a new file from the remote feed. After the communication link is disconnected, the X.* files are processed and the news files added to /usr4. The df command showed /usr adding freed blocks and inodes to its free lists while the block/inode counts were decreasing on /usr4. I have watched two news transfers in this way. During one of them the inode count for /usr4 suddenly jumped from about 2875 to 0! The following information shows a few lines of output produced after the jump by the df commands and a ps -ef command (edited to show only the germane processes). ------------------------------ /usr4 (/dev/dsk/c1d1sa ): 28470 blocks 1 i-nodes /usr4 (/dev/dsk/c1d1sa ): 28464 blocks 0 i-nodes /usr4 (/dev/dsk/c1d1sa ): 28470 blocks 1 i-nodes UID PID PPID C STIME TTY TIME COMMAND uucp 7919 1 0 02:48:57 ? 0:10 UUXQT -sumbc3 uucp 8605 7919 0 03:16:12 ? 0:00 sh -c PATH=/bin:/usr/bin:/usr/lbin LOGNAME=uucp UU_MACHINE=umbc3 UU_USER=root uucp 8606 8605 21 03:16:13 ? 0:02 rnews uucp 8607 8606 14 03:16:14 ? 0:04 compress -d uucp 8635 8606 40 03:17:03 ? 0:01 rnews /usr4 (/dev/dsk/c1d1sa ): 28470 blocks 1 i-nodes /usr4 (/dev/dsk/c1d1sa ): 28468 blocks 0 i-nodes /usr4 (/dev/dsk/c1d1sa ): 28470 blocks 1 i-nodes ------------------------------ QUESTIONS: Has anyone observed this behavior before? Is there a known bug in news2.11 or SysV software? Is there a patch for this problem? Please send a copy to me. Can anyone suggest some automated ways to monitor the news transfer to located the source of the problem? Do you have a shell or C program that can help with this task? PLEASE: Because we are losing some of our news, reply using e-mail. Thank you in advance. A. Hybl ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland Cosy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------