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