Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!icdoc!qmw-cs!bilpin!nick From: nick@bilpin.UUCP (nick) Newsgroups: comp.sys.ncr Subject: Re: Huge directory Summary: Directories never shrink Message-ID: <206@bilpin.UUCP> Date: 12 Sep 90 08:50:01 GMT References: <309@gandp> Organization: SRL Data, London, England Lines: 43 In article <309@gandp>, rg@gandp (Dick Gill) writes: > A client's 32/650 is producing a "Huge directory" message when > find is used to access a particular directory. We moved some > files elsewhere, but still get the message; there are 1401 files > in the directory now. Ah - but of course directories never shrink. If you want to get rid of this message do the following: mvdir mkdir cp /* > > How much of a problem is this? Is there a maximum number of > files in a directory before something unpleasant happens? > Well - yes. There is no easy answer to this one. Large directories are a problem (see below), but you will generally find that certain commands fail first. 'ls -l' , cp * etc etc. Actually this really is a problem. You will see a reduction in performance as these large directories, including entries relating to deleted files are searched. You should try to make sure that your directory fits into a logical file system block (512 bytes / 1K / 4K ) using NFFS (NCR Fast File System) available under NCR's Unix V.3 MB1 platform. You only have the 1K option if you are still on V.2. To check whether you have efficient directory scanning use 'sar' with the '-a' flag. If dirblk/s > igets/s then many large directories are being searched. You should also check that your PATH variable is as small as it can be, and that applications find files via relative rather that absolute path names. regards Nick -- _______________________________________________________________________________ Nick Price SRL Data || Apple link : UK0001 1 Perren Street London NW5 3ED || UUCP : nick@bilpin.uucp Phone: +44 1 485 6665 || Path : nick@bilpin.co.uk