eggert@sundae.sm.unisys.com (Paul Eggert) (12/01/88)
Guy Harris writes that "ncheck", both on S5R3 and 4.3BSD, has an "-s" flag to look for both suid-files and special device files. He also writes "I suspect it may do so faster than, say, 'find'." On a Sun-3/160 fileserver under SunOS 4.0, I tried "ncheck -s". Sometimes it dumped core. Sometimes it silently missed files. I persevered until I found a filesystem where it operated correctly. It took 25% more wallclock time than "find", and 60% more user+system CPU time. Beware "ncheck -s".
rta@pixar.UUCP (Rick Ace) (12/13/88)
In article <5552@sdcrdcf.sm.unisys.com>, eggert@sundae.sm.unisys.com (Paul Eggert) writes: > Guy Harris writes that "ncheck", both on S5R3 and 4.3BSD, > has an "-s" flag to look for both suid-files and special device files. > He also writes "I suspect it may do so faster than, say, 'find'." > > On a Sun-3/160 fileserver under SunOS 4.0, I tried "ncheck -s". > Sometimes it dumped core. Sometimes it silently missed files. > I persevered until I found a filesystem where it operated correctly. > It took 25% more wallclock time than "find", and 60% more user+system CPU time. > Beware "ncheck -s". ncheck (when it works properly) is an efficient tool for scanning a filesystem. The 4.2bsd version of ncheck, however, suffered from some problems. The most serious of these, I recall, was an error in the logic of a routine that read directory blocks, causing 1) a performance problem (the same directory block was being re-read unnecessarily), and 2) incorrect behavior on directories exceeding a certain length (ncheck would simply not report some filenames that did indeed exist within the filesystem). From the symptoms you described, it sounds as though the ncheck you're running might have this bug (this is very plausible since SunOS was derived from 4.2bsd). (Another bug appeared in the code that read the superblock; the code read 8192 bytes into a "struct fs", which is approx. 1300 bytes long, overwriting whatever data structure(s) the loader happened to place immediately after the "struct fs" in memory. This bug was not the killer, though.) Rick Ace Pixar 3240 Kerner Blvd, San Rafael CA 94901 ...!{sun,ucbvax}!pixar!rta