Mac Running Slow: Disk Errors Causing Performance Issues

LIMEHAWK - Managed IT

Home>Incident Reports>Mac Running Slow: Disk Errors Causing Performance Issues

Incident

Graphic designer called in saying her MacBook was "unusably slow" any time she was working with large Photoshop files. Saves took minutes. Finder beach-balled on basic operations. She'd already done the obvious thing — ran Disk Utility First Aid on her boot volume, got the green "The volume appears to be OK" message, and called us because she was out of ideas. Activity Monitor was showing disk I/O pegged even when nothing should have been hitting the disk.

Investigation

M1 Pro MacBook Pro from 2021, 1TB internal SSD, APFS with three volumes on the container (Macintosh HD, Macintosh HD - Data, and a small preboot). Free space was 340GB so that wasn't the problem. SMART reported Verified, so the drive hardware wasn't failing either. On paper everything looked fine.

The catch with Disk Utility's First Aid from within the running OS is that it can only do so much. It's a quick verify pass and it has to work around live system files. Plenty of filesystem inconsistencies — especially at the APFS container level — don't surface in that check. If you want real coverage you have to verify the container, each volume's B-tree structure, AND the SMART/ATA data separately.

- model: MacBook Pro 2021 (M1 Pro)
- storage: 1TB APFS, 3 volumes
- free space: 340GB (not the issue)
- SMART status: Verified (not a hardware fault)

Solution

We wrote a shell script that does a proper read-only sweep: partition map check, APFS container verify, per-volume verify, and a SMART pull via smartctl. All of it is non-destructive — diskutil's verify subcommands don't write anything, so it's safe to run on a production machine without taking it offline.

What it checks

Script walks every mounted disk and does the full stack of checks. `diskutil verifyDisk` handles the partition map. `diskutil apfs verify` hits the container superblock and space manager. Per-volume verify runs the catalog/B-tree check on each APFS or HFS+ volume. smartctl pulls the SMART data that Disk Utility only summarizes. Read-only throughout — it's a diagnostic, not a repair.

- partition maps: GPT/MBR structure integrity
- APFS containers: superblock and space manager
- APFS volumes: per-volume B-tree and catalog
- HFS+ volumes: catalog file and extents overflow
- SMART data: full drive health indicators via smartctl

Outcome

Scan flagged what First Aid missed: errors on both Macintosh HD and Macintosh HD - Data. Partition map was clean, SMART was clean, so this was pure filesystem corruption — probably from an ungraceful shutdown at some point. The important thing about macOS disk repair is that you cannot repair the boot volume while you're booted from it. You have to go to Recovery.

We rebooted into Recovery Mode (hold power on Apple Silicon until options appear), launched Disk Utility from there, and ran First Aid against the container. From Recovery it has the write access it needs to actually fix things. Both volumes came back clean. Back in the OS, Photoshop saves were instant again and Finder stopped beach-balling.

- disk0 partition map: OK
- Macintosh HD: errors found, repaired from Recovery
- Macintosh HD - Data: errors found, repaired from Recovery
- SMART status: Verified throughout
- performance: returned to normal

Key takeaways

Takeaway

Disk Utility from the running OS has limited repair ability.

Takeaway

a deep scan catches what quick First Aid misses.

Takeaway

APFS needs container-level verification, not just per-volume.

Takeaway

you have to boot to Recovery to actually repair the system volume.

Need help with something like this? Contact us

• Lenovo ThinkBook Camera Stuck in DFU Mode After Update (Hardware)