I have a lot of binary files I need to copy to a folder. The folder is already filled with files of the same name. Copying on top of the old files takes MUCH longer than if I were to delete the old files then copy the new files to the now-empty folder. This result is specific to one system - another unix system I'm using does not show the same results.
I don't know the system specifications, so I won't be able to post them (sorry). I'm just looking for ideas as to why I could be getting these results, and ideas to try to eliminate the problem. Thanks!
Also consider that
IF:
directory has large numbers of entries - >40K (varies with filesystem type)
Cure: make a directory tree, with each subdirectory having way smaller numbers of files.
Overly full disks can result in fragmented files which trashes update (cp overlay) performance of larger files.
So: You can experience lots of delay finding and overwriting files.
Another cause is poor inode caching. This is OS specific, I cannot comment specifically. But when you try to find a file in a directory, the kernel checks the inode cache first. If it finds the file in the cache it can open the file right away without having to scan thru a huge directory. inode caching also impacts the efficiency of PATH searching.
The problem could be a lot of things. The slow system could just be a slow system. The file system could be almost full, making it slower. It could be on disk(s) that are shared with other very busy file systems.
The more data you provide, the more help you'll get.
What type of Unix? What's the result from running "uname -a"?
What type of file system? How big is the file system? How full is it?