It is really hard to imagine that directory itself may be 3GB big. The size of directory is determined by the maximal sum of lengths of directory entries it ever contained at the same time. Because the length of directory entry determined mainly by the file name length (the entry contain the file name and some small amount of filesystem internal information such as inode number). Assuming that all the file names in that directory were 256 bytes long (of course, it is much more than the length of usual file names) we can see that a 3GB directory should contain about 12 million files with such names at the same time. I think that it is unrealistic for /var/spool/mqueue (which is the directory mentioned of an initial question) unless it is on an extremely big mail server. However, mail servers running under such load are usually running on muptiple computers and do not keep its queues in one directory. Most probably, the reason for the problem with the space not freeing after deleting of the directory contents is due to files which still open even after erasing its directory entries (I think that linking of one file to multiple directories is not common for /var/spool/mqueue). The problem may be identified by rebooting the computer. In this case it will be guaranteed that all still-open deleted files will be actually deleted from the file system and the space occupied by them will be reclaimed as free. In contrast, if the reason is cross-linking of files or the size of directory itself, the free space reported by 'du' will not increase after reboot. Alexey Fadyushin. Brainbench MVP for Linux http://www.brainbench.com > -----Original Message----- > From: fedora-list-bounces@xxxxxxxxxx [mailto:fedora-list- > bounces@xxxxxxxxxx] On Behalf Of Steven W. Orr > Sent: Thursday, November 30, 2006 5:44 PM > To: For users of Fedora > Subject: SUSPECT: Re: Directory Size problem > > On Thursday, Nov 30th 2006 at 08:51 -0000, quoth Dan Track: > > =>Thank you very much for the gem of a tip. That is the issue. > => > =>Many Thanks > =>Dan > > Sorry, but I believe that this is not the issue. The size of a directory > is in fact determined by the maximum number of files tha the directory > ever contained. (Something in the back of my mind seems to remember > somethingf about the number of files in a directory exceeding 188 to cause > the directory to go from 1 block to 2 blocks. I'm probably wrong about the > exact number.) Your problem is in the 3Gig region so the size of the > directory is not an issue. Don't confuse the size of the directory with > the size of the content of the directory. > > Every file has two counters on it in the file system. One counter is the > number of links on the file. Every file is allowed to have multiple names. > That's what the ln command is all about. (That's ln without the -s > option.) If you delete a file then the file doesn't actually get its > storage reclaimed unless the last name to the file is deleted. That's why > the systemcall to delete a file is called unlink(2). The other counter > that exists on a file is the open count. If a file is opened and then > deleted, the file strorage is not reclaimed until the last open channel is > closed. If a file is opened by multiple channels then this phenomenum will > occur. > > Just for fun, create a big file for yourself: > > dd if=/dev/zero of=/tmp/foo count=1M > ln /tmp/foo /tmp/bar > { read ; sleep 1000; } < /tmp/foo & > { read ; sleep 1000; } < /tmp/bar & > rm /tmp/foo > > Play with these commands and you'll see all of this stuff come into play. > > -- > fedora-list mailing list > fedora-list@xxxxxxxxxx > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
