Trace disk activity, files, and crashes

When the disk is grinding or filling up, you want two facts: which process is doing the writing, and to which paths. When an app dies, you want the report it left behind. Both are answerable without deleting anything.

Who is hitting the disk

Use Activity Monitor’s Disk view and lsof to identify the process and open paths. The Disk view’s Bytes Written and Bytes Read columns, sorted descending, name the busy process. Then list what it has open:

lsof -p 1234 | grep -v '\.dylib' | head -20

The NAME column gives you the actual paths, and filtering out libraries keeps the list readable.

For a short authorized trace, fs_usage can show live filesystem calls but produces sensitive, noisy output and may require elevated access:

sudo fs_usage -w -f filesys 1234

Each line shows the syscall, the path, and the elapsed time. Watch for a few seconds, then stop with Ctrl-C. That is usually enough to catch a process rewriting the same cache file in a loop.

Where crash reports live

Crash reports live in the user or system DiagnosticReports directories and can also be viewed through Console:

ls -lt ~/Library/Logs/DiagnosticReports | head
ls -lt /Library/Logs/DiagnosticReports | head

User processes report to the first, system daemons to the second. Recent reports are .ips files named after the process and timestamp. Open one in Console (Crash Reports section) or read it directly.

Match process name, timestamp, version, exception, and crashed thread. Concretely: confirm the timestamp matches your incident, record the app version, then read Exception Type (for example EXC_BAD_ACCESS (SIGSEGV)) and jump to the thread marked Crashed. Its stack is the heart of the report and what a developer needs.

Keep the evidence

Do not delete caches or reports before preserving the evidence that explains the failure. “Cleanup” utilities that purge DiagnosticReports destroy the only record of why the app died. Copy the relevant .ips file somewhere safe first; free the disk space second.