Smart questions
Smart answers
Smart people
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Member Login

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips now!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

Join Tek-Tips
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

LINK TO THIS FORUM!

Add Stickiness To Your Site By Linking To This Professionally Managed Technical Forum.
Just copy and paste the
code below into your site.

Partner With Us!

"Best Of Breed" Forums Add Stickiness To Your Site
Partner Button
(Download This Button Today!)

Feedback

"...Many thanks to you for putting it together and to the forum members for taking the time to post their replies and give their time to help others. Their isn't another site that can touch it..."

Geography

Where in the world do Tek-Tips members come from?
Calator (Programmer)
17 Nov 05 0:04
we run Digital UNIX V4.0D

We plan to purge some archive directories, deleting thousand of older files.

Depending on how directories are implemented by Unix,
I imagine that after removal of the files, the directory could still be quite large and may consist of many "empty" slots. Although files had been removed, most commands could still be slow while processing the directory in order to access remaining files, so performance would be poor.

If that was the case, is there a "compacting" command we need to run over the directories after removing files?

The alternative is that a directory list is rebuilt as files get removed, so that the directory consists only of occupied slots at any one time - is that the case?
Helpful Member!  Mike042 (MIS)
17 Nov 05 4:17
You are almost correct in your understanding of "how directories are implemented by Unix". The "directory file" contains file headers and their i-nodes.  When a file is deleted the i-node number is only dis-associated from the filename so no "empty slots" appear (and hence why "directory files" never seem to get smaller when some of their files are deleted).  This is demonstrated by using the command strings /path/to/dir and seeing that dir contains the filenames of all the files it has ever had in it.

As far as I know their is no easy way to "compact" the directory.  However here is an idea for a simple process to do what you want for directory /path/to/dir :
1) delete all files that are not required from /path/to/dir
2) tar up the contents of /path/to/dir to a tar-file in /tmp
3) note the ownership and permissions of /path/to/dir
4) delete the directory /path/to/dir (use rm -rf)
5) re-create the directory with the correct ownership and permissions
6) un-tar the tar-file from /tmp into /path/to/dir

I hope that helps.

Mike
 
Calator (Programmer)
17 Nov 05 18:46
Hi,
Thanks a lot for the info. Before applying the method you described, I need to clarify one aspect:
- is leaving directory as is after removal of thousand of files going to affect performance of various commands over that directory? is compacting going to improve performance?
this will have to do with an undestanding of how Unix processes the directory
Mike042 (MIS)
21 Nov 05 5:40
I haven't carried out any performance tests to check this, other people may have.  However I would guess that there might be a slight performance issue with many thousands of files.  Having said that, UNIX in general does have good sorting and list processing methods, as well as 'caching' algorithms.  So you might be investing a huge amount of time and effort for minimal savings.  In my experience of UNIX (so far) I have not needed try to 'compact' directories.

I hope that helps.

Mike
Rexxy (MIS)
7 May 06 23:06
if your not having any issues now, then there will be not change after the removals are done.....if there are major slows etc now, it will still need to run through the hierachial directory structure and will most likely still be just as slow....

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close