SUMMARY: VxFS and lsof

Thanks to Tristan Ball for the only answer on this.

He tells me how the conversion works between inode and 
filename, but doesn't go on to explain why it doesn't 
work under lsof :)  However, I drew my own conclusion 
from his comments, and I believe that lsof does not go 
to the filesystem to get the filename if it's not in the
cache within the kernel.  How it's possible for it to do
that, I don't know - perhaps because it's a process 
which will probably interact directly with the kernel to
get its information.

He doesn't think this lack of name will cause a problem,
unless the app is horrendously written.  I've no solid 
evidence right now to say that the process I'm looking at 
really has a problem when the filename's not in the 
cache - I don't see why it would, since I know from truss
that it's only accessing the file handle.  As such, I'm 
happy to put the behaviour down to fortuitous timing.

Until I've got more evidence, at least...

Cheers,

Stuart.

Original question:

> Gurus,
> 
> I'm wondering if anyone can shed any light on this issue.
> 
> If I check a process under lsof, I see that it has a
> number of files open on a filesystem, but it doesn't tell
> me the names of those files.  However, it shows the inode,
> which allows me to run find /<FS> -inum <number> to check
> the filename.  This runs successfully, and at the next
> run of lsof, I get the filenames shown correctly for that
> filesystem - all of them.
> 
> I'm suspicious that this is causing problems for the
> application, though this is just a gut feel at this time.
> Things appear hung, so I try debugging with truss and
> lsof, and things start running again when the file is
> identified by find.  Or from the twice that I've seen
> this, maybe it's just coincidence.
> 
> I've seen this on HP as well, so it's not just Solaris
> specific.  If anyone has any ideas of what's going on
> here, I'd love to hear them.  If not, I'll try the HP
> admin list, then post a summary to both (if I get an
> answer).
> 
> TIA,
> 
> Stuart.
> _______________________________________________
> sunmanagers mailing list
> sunmanagers@sunmanagers.org
> http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers