fsck -n /dev/rdsk/c......

which will check the partiton without making any changes and give you some stats at the end including percentage fragmentation. If the fragmentation value is above single figures then consider doing a ufsdump of the partition, remaking it with newfs and doing a ufsrestore -rvf. It is extremely rare in my experience to need to do this.

If on the other hand you actually want to unlink all of the directories and files on the partition, don't bother, just newfs it.

I hope this is useful.

Cheers,

JohnGG

The Unix sa here is saying that there is no benefit in doing a mv and re-creating the directory.

I think JohnGG is saying the same.

bruce is saying that there is a potential performance issue if I just delete the files (keeping the last 30 days files only) - as the directory file will still reflect the previous size?

Any other views?

Thanks

When a directory is created on a Solaris 8 platform it has a size of 8k. If you add a lot of files to that directory then that 8k will get expanded to cope. If you then delete most of those files the directory will not shrink back to 8k which is what bruceb3 points out. However, we are only talking a few kilobytes here and you are probably not going to have lots of directories all with enough files to cause the expansion. So I agree with your SA that it's not going to gain you much. If you contemplate a filesystem where there are going to be huge numbers of very small files (or symlinks, perhaps) you may run out of inodes before you run out of data space so consider reducing the bytes per inode when making the filesystem with newfs. Conversely, if you have a files system that has just a few large files, perhaps database files, increase the bytes per inode, thus creating fewer inodes and leaving more space for data.

Cheers,

JohnGG

The way to fix this is to cleanup the directory and then rename it and then recreate the directory.

e.g.

cd /var/spool/mqeueue
mv mqueue old.mqueue
mkdir mqueue
chown xxx:xxx mqueue
chmod xxx mqueue
rm -rf old.mqueue
[download]

Get whatever you need from the old.mqueue directory before removing it, obviously.

mkfs /dev/part2 
mount /dev/part2 /mnt/tmp
cp -a /mnt/mountpoint /mnt/tmp
umount /mnt/tmp
mount /dev/part2 /mnt/mountpoint
umount /dev/part1
[download]

Data processing of file content was moderated by getting file names from mysql. For reasons I don't understand, access to specific files by name was never much of a problem (well, I wasn't in charge of the processes involved, but the person who was apparently didn't have any serious trouble of this sort).

Of course, any other process that relied on a full scan or wildcard search of the directory (e.g. "ls", "find", system backups, anything using readdir, ...) became horribly bogged down, and upon going into this directory, would run for hours before finishing.

I think part of the problem was that files were constantly being created at a rate of dozens per minute -- a lot would change in the time it took to do a complete scan. But most of the problem was just the size of number of files in the directory. (I learned that the memory footprint of freebsd "find" grew perversely when it had to walk through this thing.)

Interestingly, as we got around to cleaning up the mess (so that a "daily" backup could finish within a day), we found that once we stopped creating new files and reduced the number of standing files to 100,000 or less, the response time for full scans became fairly acceptable, even though the disk space consumed by the directory file itself had not been reduced. (Unix/linux directory files do not shrink when the files they contain are deleted).

I sort of wish I knew more about how the contributing factors interact, but I've concluded from other experiences that reducing the file count is probably the biggest factor.

But the more relevant lesson, I think, is to avoid any processing strategy that would populate a directory like that. Just don't do it.

find /path/to/you/directory -type -f -mtime +30 -exec rm -f {} \;
[download]