New answers tagged lsof
You are right in assuming that lsof uses the inode from the kernel's name cache. Under Linux platforms, the path name is provided by the Linux /proc file system. The handling of hard links is better explained in the FAQ: 3.3.4 Why doesn't lsof report the "correct" hard linked file path name? When lsof reports a rightmost path name component ...
A good alternative is psgrep -d , lsof -p $(pgrep -d , postgres) -d Specifies the delimeter.
lsof lists open files, and mmap(2) can access data after the file descriptor is closed or even unlink-ed (it is using an i-node), but /proc/$PID/maps try to show something about them.
Too fast diagnosis I read online that this might be resolved by repairing permission on the drive. Unfortunatly, from the description of your problem, this is wrong. What need to be repaired is the filesystem on your external disk SEAGATE. Analysis of lsof The output of your lsof command tells that the command mds (1st column) is actually reading ...
It appears that Spotlight is indexing this drive. There could be a problem that is causing Spotlight to hang up and constantly pound this drive. The mds process is the metadata server. Try killing this process and then tell spotlight to not index this drive. To disable spotlight indexing go to System Preferences -> Spotlight -> Privacy and add the disk to ...
Top 50 recent answers are included