Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have detected performance issues in a Solaris 10 process and observed too much writes to descriptor 268 using truss.

We don't have lsof at hand, but here is an excerpt from pfiles output:

 268: S_IFREG mode:0644 dev:321,11003 ino:13621 uid:101 gid:105 size:100014416

Is there a way to know the real file path from this information?

Thank you.

share|improve this question
up vote 2 down vote accepted

The ino value is the inode of the file on the filesystem, in your case 13621 so you could use find's -inum option like so (where $filesystem_name is a filesystem on your machine:

find /$filesystem_name -inum 13621

Inodes are unique per filesystem, so if you have multiple filesystems you might want to check them individually.

There are some nice dtrace scripts on the web for finding activity on filesystems:

share|improve this answer
Is there a way to know which filesystem to search into from the pfiles info? – fglez Jul 14 '10 at 6:56
The dev:321,11003 will be the major/minor number of the filesystem. – davey Jul 14 '10 at 9:19
ls -lL will show you major minor numbers. Do ls -lL on the underlying disks to discover yours. – davey Jul 14 '10 at 9:54
Sorry, but I can't find that info. Could you please provide a sample ls -lL output? – fglez Jul 14 '10 at 11:52

The file path should appear just after the line you posted. If it isn't there, it is likely to have been removed earlier.

share|improve this answer
You're right the path was displayed for other files. Is the file being removed the only reason for not displaying the path? Why then is the reference still open? – fglez Jul 14 '10 at 8:52
If a process has an open file handle and the file has been rm'ed by somebody else then there would be no filename. – davey Jul 14 '10 at 9:52
I guess that could be the case if rotating log files... – fglez Jul 14 '10 at 11:53
There are no other reasons I'm aware of for pfiles not to display the filename. A bogus log file rotation would be a likely cause indeed. As long as at least a process has the removed file open, its contents, despite being unreachable, will keep using more and more disk space. The only clean way to end that situation is to restart the process, or at least have it reopen the log file, if it implements that feature. – jlliagre Jul 16 '10 at 0:38

You can possibly look for the open() call that resulted in filehandle 268 and see what params it was called with.

I'm not familiar with the particulars of Solaris's /proc filesystem, but /proc/fd/ under linux has a list of open filedescriptors and what they're opening; if Solaris has something similar, that might help.

share|improve this answer
After several tries we were lucky to catch the call when file was being rotated, but I would like to know a way to get the path when there's no open() captured. – fglez Jul 15 '10 at 5:46
The pathname used to open a file isn't recorded anywhere after that file has been deleted. You can still see its content by using this path: /proc/<pid>/path/<filedescriptor>. – jlliagre Jul 16 '10 at 1:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.