The lsof command lists all open files. You should look for any files on the problematic volume, because you can’t eject a volume while something has an open file on that volume.
For example, if I go looking for open files on my Time Machine volume, I would run lsof and filter it through the grep command to only show entries containing /Volumes/Time Machine in the path:
$ sudo lsof +c 0 | grep "Volumes/Time Machine"
mds 126 root 26r DIR 1,15 192 2 /Volumes/Time Machine
mds 126 root 27r DIR 1,15 3296 19 /Volumes/Time Machine/.Spotlight-V100/Store-V2/3D55DE01-E241-4BC2-AC3A-4728752E5C9C
...
revisiond 157 root 10r DIR 1,15 192 2 /Volumes/Time Machine
revisiond 157 root 11r DIR 1,15 288 18441702 /Volumes/Time Machine/.DocumentRevisions-V100
...
mds_stores 342 root txt REG 1,15 16384 11887988 /Volumes/Time Machine/.Spotlight-V100/Store-V2/3D55DE01-E241-4BC2-AC3A-4728752E5C9C/live.2.indexCompactDirectory
mds_stores 342 root txt REG 1,15 56 52 /Volumes/Time Machine/.Spotlight-V100/Store-V2/3D55DE01-E241-4BC2-AC3A-4728752E5C9C/dbStr-1.map.header
mds_stores 342 root txt REG 1,15 56 56 /Volumes/Time Machine/.Spotlight-V100/Store-V2/3D55DE01-E241-4BC2-AC3A-4728752E5C9C/dbStr-2.map.header
...
The +c 0 option tells it to not truncate process names (in the first column of output). Otherwise, they are truncated to 9 characters.
The above ouput is abbreviated, and I’ve removed a lot of horizontal whitespace to make it easier to read here, but the important take-away is that three processes: mds, revisiond and mds_stores have a lot of open files on the Time Machine volume. These are not unusual:
- mds is the “Metadata Server”, a key component of Spotlight
- revisiond is for tracking and managing file revisions.
- mds_stores is Spotlight’s core indexing service.
Note that if your volume is not yet mounted, then software accessing it will be doing so through one of the “device” files, /dev/disk*. In my case, nothing is holding the device open, which should be expected unless a low-level disk utility (e.g. repartition, erase, repair, etc.) is running on the device:
$ sudo lsof +c 0 | grep "/dev/disk"
The ps command lists all processes running. By default, it only shows processes that belong to the user typing the command, which are mapped to a (physical or virtual) terminal device. But you can use the “a” option to show processes belonging to all users and the “x” option to show processes that aren’t mapped to a terminal.
The full set of processes is not typically useful, but you can use it in conjunction with a grep command to look for specific processes. For instance if I want to see information about the logind process (which manages user logins):
$ ps ax | grep logind
156 ?? Ss 0:04.93 /System/Library/CoreServices/logind
31431 s000 S+ 0:00.00 grep logind
Note that the output includes the full command-line of each command, including its parameters. So the grep filter picked up itself, because logind appeared on its command-line.
If you want to look to see if fsck is running:
$ ps ax | grep fsck
31457 s000 S+ 0:00.00 grep fsck
In my example, it isn’t running, so the only match is the grep command itself.
Great. This means that whatever was running (and therefore holding open files, preventing unmounting) has finished. Given the original screen-shot, it was almost certainly the mds_stores process, which is Spotlight’s indexing daemon.
As for why it couldn’t be interrupted (and was therefore blocking the unmount), I can only speculate, but it may well be that it was reading and analyzing that 5GB file. It may only be able to pause itself between files, not while processing a single file.
Previously, you force-unmounted the drive before mds_stores finished or got to a checkpoint, which probably caused it to start over.
