Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
      O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE
 [...]

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

Thank you.

share|improve this question
add comment

3 Answers

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:

http://forums.sun.com/thread.jspa?threadID=5075136

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
add comment

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
add comment

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
add comment

Your Answer

 
discard

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.