Date: Wed, 22 Nov 2000 12:47:10 +1100 From: Zero Sum <count@shalimar.net.au> To: "Human" <human@adept.co.za>, "freebsdquestions" <questions@FreeBSD.ORG> Subject: Re: filesystem/dir file? Message-ID: <00112212471005.05727@shalimar.net.au> In-Reply-To: <NEBBIDNMEDIIMNICEJOBOEEFCEAA.human@adept.co.za> References: <NEBBIDNMEDIIMNICEJOBOEEFCEAA.human@adept.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 22 November 2000 03:36, Human wrote: > HI > > Ive tried this in SCO UW7, Redhat and FBSD 4.0. > > If u make a empty directory and then run a script in it to produce a couple > thousand empty files , u will note that the size of the actual directory > file increases, which is normal because the actual file names of the files u > have created in the dir and their inode numbers are stored in the directory > file. The strange thing is once u delete the files in the directory the size > of the directory file does NOT decrease, why??? I presume the reference to > the file is removed but it seems (im not sure about the wording) the > placeholder or buffer in the directory file does not get removed therefore > it stays the same size. > > My question is why does it not empty the file properly this seems like a > large waste of space, the only conclusion I can come to is in the old days > (b4 I was born) computers were too slow and it would have used up > unnecessary resources????? > Any one have a better theory? > It is the way directory entries work, I Unix a directory entry is just a 'link'. A two coloumn table entry containing the inode number and the file name. This is why rm does not delete anything. It hust removes the link as there may be other links. Execute permission on a directory means the ability to make the association between the two coloumns (see execute *is* appropriate). Read permission allows you to see the links in the directory (but not the files) and write allows you to modify the directory. Table entries are created as they are needed, unsorted, unordered. i.e. The directory files are grown by a block when all table entries are full. Put a lage number of files in a directory, you get a big directory. Remove a few links and you wind up with empty slots in the table, but *no adjustments are made* to the table structure, it does not "shrink". This would make for a very inefficient file system, even today. it is a maintenance function, not 'in-process' function. Directories are always read sequentially (since they are not ordered) and placing any serious number of files in a single large directory is a no-no. It can add considerably to your I/O time. I know where there is a Solaris box that takes 10 minutes to do an 'ls' of a given directory (14,000 entries). I know of no utility to shrink directories. The old technique to do this was to make a new one move the files to it, delete the old one and rename the new one. This was part of system tuning (regular maintenance) and I used to have scripts to do this. I can't see any reason why a "shrinking" utility could not be written that would shrink directories though... But I've never seen one. And it never occured to me to write one. Avoiding the problem is not too hard. Geoff -- count@shalimar.net.au Nihil curo de ista tua stulta superstitione To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00112212471005.05727>