Solaris

Hello,

I am running some performance based tests on Solaris, and I was wondering how fast the "seeking" rate of Solaris is, or how fast Solaris can get information about files with the "find" command. Does anyone know what 'find' command I could run to traverse through my system to see the rate of files scanned/hour?

Thanks in advance

Long version:
Solaris has an inode cache. So as long as the file in question is cached in the inode cache, there is very little overhead on calling stat() - which is how find works. Look up the man page for either ftw() or nftw().

Once you stat() a file, the inode will get cached if it was not in there. Eventually the cache fills up and some inodes get moved out.

Bottom line: So when you hit the indoe cache you are in kernel you are not testing disk I/O.

So, you are not measuring what you think you're trying to measure by trying find.

I/O is hard to test as a one-off operation
Why? inode caching, different disk controller types, disk speeds (rotational latency), i/o queue request length, file data caching all contribute to how fast/slow you can access a file's data and metadata on disk.

Modern systems with fast disks and no competition for the disk can usually read the first few hundred blocks of a file that is not cached anywhere in something under ~10 milliseconds.

Short answer: don't use find. use nftw() and open() and read() in a simple piece of C.
If you use the shell, remember most commands involve opening files, lots of files, over and over again. Not all commands do this but most do.

Try this:

Code:

truss -t open /usr/bin/ls

Note how many files are opened just to run this one simple command.

You get around most of this extra file activity by using one piece of code to try to open all the files on your disk and read one block.

To actually test seek times accurately you need to do something like timing driver-mode code to ask a drive to seek all over the place. Some disk vendors have benchmarking code or disk controller test code that does this. You have to run it as root against a dismounted disk. See if you can find code for your disks.