Hi Elvin, George,
Just to follow this up. Although setting fs.scaninterval to 0 results in all files being skipped according to the log message, we were still seeing updated ctimes for all files in an FS that correlate with the last scan time.
e.g.
[root@antares-eos08 ~]# grep ScanDir /var/log/messages | grep sdb | tail -n 1
Jul 8 14:54:15 antares-eos08 scandir[4078328]: [ScanDir] Directory: /eos/data-sdb files=440 scanduration=0 [s] scansize=0 [Bytes] [ 0 MB ] scannedfiles=0 corruptedfiles=0 hwcorrupted=0 skippedfiles=440 disk_scan_interval_sec=14400
[root@antares-eos08 ~]#
[root@antares-eos08 ~]# stat /eos/data-sdb/00015107/336d3893
File: /eos/data-sdb/00015107/336d3893
Size: 7383396635 Blocks: 14420704 IO Block: 4096 regular file
Device: 801h/2049d Inode: 5049 Links: 1
Access: (0600/-rw-------) Uid: ( 2/ daemon) Gid: ( 2/ daemon)
Access: 2024-06-28 03:49:01.977472005 +0100
Modify: 2024-06-20 23:12:05.096592532 +0100
Change: 2024-07-08 14:54:15.201298815 +0100
Birth: 2024-06-20 23:11:46.339897080 +0100
[root@antares-eos08 ~]#
(these FSTs are running EOS 5.2.23)
Setting {space,fs}.scanrate to 0 also didn’t help. I also restarted the FSTs just in case it needed a kick needed to pick up the settings, but no joy.
In the end, I set a week long fs.scan_disk_interval, which is enough time for the CTA FST garbage collection to clean up old files between the scans.
I feel like I probably missing something here, there are quite a number of filesystem ‘scan’ related settings, and I could believe we’ve done something silly. I also couldn’t obviously see what attribute was actually being updated to trigger the ctime update.
A more appropriate fix might be for the CTA FST garbage collection to look at the mtime instead of the ctime, but that’s a discussion for elsewhere.
Thanks,
Tom