Post

Replies

Boosts

Views

Activity

Reply to SystemLanguageModel.Adapter leaks ~100MB of irrecoverable APFS disk space per call
Great analysis tbrrss! That pointed me in the right direction. I ran fs_usage -f diskio -w | grep AppModelAssets while triggering two adapter calls and confirmed the behavior: each invocation writes lora.part.bin + metadata.json to a new subdirectory with a unique hash. Two consecutive calls, same adapter, same machine — two different hashes (3a0bede9... and d42d8d5a...). So it's not content-addressed, it's generating a new UUID every time. From booted macOS, sudo ls and sudo find on /private/var/db/AppleIntelligencePlatform/AppModelAssets/ both return "Operation not permitted" — SIP blocks access entirely. That's why du couldn't account for the space and why it looked like a filesystem-level issue. Booted into Recovery Mode (which bypasses SIP), and there they were: 1,684 hash directories, each containing a full copy of the adapter (~160MB). That's ~269GB, matching the "missing" space almost exactly. Deleted them all with rm -rf from Recovery and the space came back immediately. So this is a caching bug in TGOnDeviceInferenceProviderService, not data loss or APFS corruption. The files are real and legitimately allocated, they're just completely invisible from userspace because SIP protects that path. No amount of fsck, purge, or Safe Mode will help because there's nothing wrong with the filesystem. The real fix from Apple would be some form of cache management, content-based hashing to deduplicate identical adapters, an LRU/TTL eviction policy, or cleanup on process exit. Right now there's zero garbage collection. For anyone hitting this, here's the workaround from Recovery Mode: Reboot into Recovery Mode (hold Power button on Apple Silicon) Open Terminal from Utilities menu diskutil apfs list — find your Data volume (e.g. disk3s5) diskutil mount disk3s5 diskutil apfs unlockVolume disk3s5 (enter your password if FileVault is enabled) ls /Volumes/Data/private/var/db/AppleIntelligencePlatform/AppModelAssets/ | wc -l — confirm the cached copies rm -rf /Volumes/Data/private/var/db/AppleIntelligencePlatform/AppModelAssets/* Reboot Updating my Feedback Assistant report with these findings.
6h
Reply to SystemLanguageModel.Adapter leaks ~100MB of irrecoverable APFS disk space per call
Great analysis tbrrss! That pointed me in the right direction. I ran fs_usage -f diskio -w | grep AppModelAssets while triggering two adapter calls and confirmed the behavior: each invocation writes lora.part.bin + metadata.json to a new subdirectory with a unique hash. Two consecutive calls, same adapter, same machine — two different hashes (3a0bede9... and d42d8d5a...). So it's not content-addressed, it's generating a new UUID every time. From booted macOS, sudo ls and sudo find on /private/var/db/AppleIntelligencePlatform/AppModelAssets/ both return "Operation not permitted" — SIP blocks access entirely. That's why du couldn't account for the space and why it looked like a filesystem-level issue. Booted into Recovery Mode (which bypasses SIP), and there they were: 1,684 hash directories, each containing a full copy of the adapter (~160MB). That's ~269GB, matching the "missing" space almost exactly. Deleted them all with rm -rf from Recovery and the space came back immediately. So this is a caching bug in TGOnDeviceInferenceProviderService, not data loss or APFS corruption. The files are real and legitimately allocated, they're just completely invisible from userspace because SIP protects that path. No amount of fsck, purge, or Safe Mode will help because there's nothing wrong with the filesystem. The real fix from Apple would be some form of cache management, content-based hashing to deduplicate identical adapters, an LRU/TTL eviction policy, or cleanup on process exit. Right now there's zero garbage collection. For anyone hitting this, here's the workaround from Recovery Mode: Reboot into Recovery Mode (hold Power button on Apple Silicon) Open Terminal from Utilities menu diskutil apfs list — find your Data volume (e.g. disk3s5) diskutil mount disk3s5 diskutil apfs unlockVolume disk3s5 (enter your password if FileVault is enabled) ls /Volumes/Data/private/var/db/AppleIntelligencePlatform/AppModelAssets/ | wc -l — confirm the cached copies rm -rf /Volumes/Data/private/var/db/AppleIntelligencePlatform/AppModelAssets/* Reboot Updating my Feedback Assistant report with these findings.
Replies
Boosts
Views
Activity
6h