/.fseventsd taking up a huge amount of disk space

[ryandesign (Ryan Carsten Schmidt)]

On the 10.9 buildbot worker, /.fseventsd is taking up a huge amount of disk space (15GB out of a 90GB disk). We run out of disk space, causing builds to fail. I don't know how to return it to a reasonable size. I did not check the other workers but they could be affected too.

[mf2k (Frank Schima)]

According ​this blog entry. You can do the following to turn off the logging.

"To keep it [fseventsd] from doing logging of filesystem events on the drive, you need to make a directory called .fseventsd and inside that folder put a single file named no_log."

[ryandesign (Ryan Carsten Schmidt)]

Thanks. I've touched /.fseventsd/no_log now. There are files in that directory with dates back to June 9, 2019. I wonder if the system will clean them up on its own (I'll wait awhile and see if they're still there) or if I have to do that somehow (just delete the files? Or use some other command?)

I also touched no_log on the 10.10 Yosemite worker, where /.fseventsd was 11GB and contains files back to September 24, 2019.

If this successfully prevents the creation of new files there and has no adverse affects on our builds, I can make the same change to the other workers.

[mf2k (Frank Schima)]

I assume you need to manually delete the existing files (with sudo rm) to free up the space.

[ryandesign (Ryan Carsten Schmidt)]

I've now additionally touched /.fseventsd/no_log on 10.14 (which had 2GB of files back to February 17, 2019), 10.12 (11GB, files back to September 26, 2019), 10.6 (0.9GB, files back to June 9, 2019) and 10.11 and 10.13 (just a few files from today since these machines were just restored from backups (#60111, #60112)).

I cannot touch /.fseventsd/no_log on 10.15 because touch: no_log: Read-only file system.

However, creating the /.fseventsd/no_log file has not prevented new entries from appearing in /.fseventsd on 10.9 and 10.10, so this does not appear to be the solution, at least not the complete solution. Maybe the OS needs to be rebooted before this takes effect. I'll reboot the servers when they're idle and then we'll wait and check again.

I haven't manually deleted any of the old files because I'd like to find documentation that assures me that's safe to do.

[ryandesign (Ryan Carsten Schmidt)]

Touched /.fseventsd/no_log on 10.6 i386, 10.7, 10.8. That's all of them now except for 10.5 ppc and 10.15.

[ryandesign (Ryan Carsten Schmidt)]

I've manually deleted files in /.fseventsd older than 1 month with: '

$ sudo -s
Password:
# cd /.fseventsd
# find -E . -type f -regex '.*/[0-9a-f]{16}' -mtime +30 -delete
# exit
$

[ryandesign (Ryan Carsten Schmidt)]

I ran the above cleanup commands again on the 10.6 thru 10.14 workers. On 10.9, 13GB of disk space was freed. On 10.6 x86_64, 1GB was freed. There were no noticeable space savings on the other workers.

[mascguy (Christopher Nielsen)]

Yeah, this is one of the few annoyances related to macOS.

Whenever I'm setting up a new VM, disk, etc, I run through the following routine for every logical volume:

$ sudo touch /Volumes/<vol_name>/.metadata_never_index
$ sudo touch /Volumes/<vol_name>/.com.apple.timemachine.donotpresent

# Ensure we can see the contents of '.fseventsd', sans sudo
$ sudo chmod g+rx,o+rx /Volumes/<vol_name>/.fseventsd

$ sudo touch /Volumes/<vol_name>/.fseventsd/no_log

# While file '.metadata_never_index' will take effect eventually, stop SpotLight indexing immediately:
$ sudo mdutil -d /Volumes/<vol_name>

It's also good to check the contents of /private/var/vm/, to see if there's a hibernate file. If so, disable that via pmset, for any non-laptop Mac... VMs included.

Ditto for checking the size of the swap file(s), which also reside in that directory.