On Mon, 25 Mar 2002, at 7:52pm, Tom Rauschenbach wrote: > This has been puzzling me for weeks. If (as root) I type > find / -print |grep somefilename > sometimes it takes many minutes, sometimes it completes in seconds ...
Sometimes the system has to walk the directory tree on disk, sometimes everything is already in cache/buffer memory. > ... and sometimes I get a new shell prompt but I can hear the disk > grinding away for many seconds after the command seems to have completed. Many filesystems maintain a notation of the "last access time" of a filesystem object. Under Unix/Linux, this is called the "atime". Directories are generally considered filesystem objects. So, when you walk the directory tree, you "touch" the atime of every directory. All of those updated atime fields then need to be written out to disk. This results in the behavior you are seeing. If you want, you can disable the atime updates. Mount the filesystem with the "noatime" option. > Does Linux really maintain a huge cache of the disk directory heirarchy ? Linux maintains a disk cache at the block level. If the most-recently accessed blocks contain directories, then directories will be cached. So if you are doing directory-intensive work, directories will be cached; otherwise, they will not. This is a Good Thing. :) -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
