SnickySnacks

Here's what I use: veto files = /._*/.DS_Store/.AppleDouble/.Trashes/.TemporaryItems/.Spotlight-V100/ delete veto files = yes

It is being excluded but I still have problems. Part of it may just be cache_dirs itself. I mentioned a possibly related issue in the cache_dirs thread but never got a reply.

I had 4GB but I've been running into some spinup issues that I think are due to cache pressure so I expanded to 16GB. 26TB, dual parity, not running VMs or dockers. But I *do* have a time machine backup which makes approximately 3 billion tiny files.

It doesn't seem to be related to file access or time machine. It happened again when I haven't used time machine in weeks. Looks like it may be stuck waiting for a timeout or something. I'm not really sure. root@tower:/usr/local/emhttp/plugins/dynamix.cache.dirs/scripts# lsof | grep cache_dir cache_dir 19058 root cwd DIR 0,2 220 7660 /usr/local/emhttp cache_dir 19058 root rtd DIR 0,2 400 2 / cache_dir 19058 root txt REG 0,2 1094752 3371 /bin/bash cache_dir 19058 root mem REG 0,2 174816 4468 /lib64/ld-2.24.so cache_dir 19058 root mem REG 0,2 18436 4425 /lib64/libtermcap.so.2.0.8 cache_dir 19058 root mem REG 0,2 18808 4480 /lib64/libdl-2.24.so cache_dir 19058 root mem REG 0,2 2067512 4474 /lib64/libc-2.24.so cache_dir 19058 root 0r FIFO 0,8 0t0 105856711 pipe cache_dir 19058 root 1w CHR 1,3 0t0 2051 /dev/null cache_dir 19058 root 2w CHR 1,3 0t0 2051 /dev/null cache_dir 19058 root 10r CHR 1,3 0t0 2051 /dev/null cache_dir 19058 root 63r FIFO 0,8 0t0 105856711 pipe root@tower:/usr/local/emhttp/plugins/dynamix.cache.dirs/scripts# lsof | grep find root@tower:/usr/local/emhttp/plugins/dynamix.cache.dirs/scripts# pstree -pl 19058 cache_dirs(19058)───timeout(6371) root@tower:/usr/local/emhttp/plugins/dynamix.cache.dirs/scripts# ps awx | grep timeout 6371 ? Z 0:00 [timeout] <defunct> 9118 pts/0 S+ 0:00 grep timeout

I've been having an issue since the 6.x release series where cache_dirs will report 100% CPU usage after I use my time machine share (via AFP). This share is explicitly excluded from cache_dirs since it contains a billion little files. cache_dirs sits at 100% in top and uses one full cpu core 3241 root 20 0 10244 2824 2100 R 100.0 0.1 80291:02 cache_dirs the disks are not spinning up, as far as I can tell. lsof doesn't report what it's actually doing (it's apparently not disk accesses as the numbers don't increase. Edit: Duh. Should have been looking for the "find" process, but still...): cache_dir 3241 root cwd DIR 0,2 400 2 / cache_dir 3241 root rtd DIR 0,2 400 2 / cache_dir 3241 root txt REG 0,2 1094752 3371 /bin/bash cache_dir 3241 root mem REG 0,2 174816 4468 /lib64/ld-2.24.so cache_dir 3241 root mem REG 0,2 18436 4425 /lib64/libtermcap.so.2.0.8 cache_dir 3241 root mem REG 0,2 18808 4480 /lib64/libdl-2.24.so cache_dir 3241 root mem REG 0,2 2067512 4474 /lib64/libc-2.24.so cache_dir 3241 root 0r CHR 1,3 0t0 2051 /dev/null cache_dir 3241 root 1w CHR 1,3 0t0 2051 /dev/null cache_dir 3241 root 2w CHR 1,3 0t0 2051 /dev/null cache_dir 3241 root 6r REG 0,2 2727 8292 /usr/local/emhttp/update.htm I thought it may be related to internal linux file caching of the files on the AFP share, but if there was an issue with cache_dirs needing to recache drives, I'd think it would show disk accesses/spin up the disks. restarting cache_dirs seems to fix it, but any idea how to debug what causes it so I don't need to manually do this every time? I've attached diagnostics, any ideas? tower-diagnostics-20170811-0212.zip

I block a few more items than this, but similar: veto files = /._*/.DS_Store/.AppleDouble/.Trashes/.TemporaryItems/.Spotlight-V100/ delete veto files = yes

So, i needed more space in my server...plus with a non-modular power supply and nothing even close to hot swap bays, putting in hard drives was a huge pain. So i decided to get a Norco 4224. In order to save some money, I didn't buy the SAS expander card, figuring that a M1015 plus two reverse breakout cables would last me for 16 drives total. However, I didn't anticipate that the reverse breakout cables wouldn't reach the last 2 sata connectors on my motherboard. Given that it's movie night (yeah, a bad time to do server upgrades) I was in a panic and about to post here, on CL, run to microcenter, and call the local system builders etc looking for sata extension cables and probably paying a premium to get them immediately rather than ordering the $0.79 cables from monoprice. Then I had a flash of insight...there's no reason the last 2 drives need to be in the case.... Cue my ghetto 4224 with a nice hood ornament. Edit: Well, my SAS cables from monoprice came in earlier than expected so now I'm running 6 drives off the mobo and 2 off the m1015 and was able to close the case. I'll hook the rest up right when the other 2 cables come in. /running parity checks now