home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!uknet!warwick!nott-cs!ucl-cs!news
- From: J.Purchase@cs.ucl.ac.uk (Jan Purchase)
- Newsgroups: comp.unix.aux
- Subject: ncheck core dumps
- Message-ID: <2994@ucl-cs.uucp>
- Date: 14 Sep 92 02:16:57 GMT
- Sender: news@cs.ucl.ac.uk
- Lines: 39
-
-
-
- Has anyone out there experienced problems using /etc/ncheck?
-
- Sometimes, when A/UX crashes, one loses an inode with no way of
- telling which file(s) it represented - thus making it difficult to
- replace. I have overcome this problem with ncheck. Using cron, I
- schedule a nightly job to ncheck all the file systems and dump the
- results in a file. If A/UX crashes and I lose an inode - I simply grep
- this file to get the corresponding file name(s) and replace them. This
- worked under A/UX 2.0.1 for over 16 months.
-
- However, recently I have noticed that ncheck core dumps (with a
- Segmentation violation, return code 139) when checking the /usr file
- system. This file system has recently been enlarged (with the
- installation of X11, prolog, epoch, etc..) to some 9000 files
- carrying about 102Mb of data. Does ncheck have an upper limit on
- number of files or filesystem size?
-
- Oddly, if I invoke ncheck from /bin/csh it crashes less often than
- when I invoke it from /bin/sh (or via cron, which uses /bin/sh). Can
- anyone shed any light on this?
-
- Setup:
-
- A/UX 2.0.1 running on Mac IIcx, 8Mb RAM, 40+210+120Mb discs
-
- "df -t /usr" gives:
-
- /usr /dev/dsk/c2d0s3 167738 blocks 81140 i-nodes
- total 371478 blocks 88704 i-nodes
-
- Many Thanks,
-
- Jan
-
- -----------------------------------------------------------------------
- Jan Purchase - University College London, UK - purchase@cs.ucl.ac.uk
- -----------------------------------------------------------------------
-