It seems the change just sets the default config parameter, and it can still be changed in the config.
The point being — i prefer “aggressive” filewalker on node start: high CPU usage for short time. I don’t want that activity to be spread out and don’t see the reason to. So I’m going to disable it on my nodes, as I don’t see any benefits. (Also from the principle: “not broken-don’t fix”).
Of course, folks with slow storage shall prefer lazy filewalker, no question about it.
If your system could already handle it there won’t be any noticeable difference. It’s not going slower, just at lower priority. So if the IO bandwidth is there, it’d still be used. I personally also like that it’s a separate process because that makes it easier to see whether it’s running or not.
There is plenty running. But file walker does not touch data, only metadata. And metadata is located on an SSD, with massive bandwidth. I observe on node start it uses 100% of a single CPU core and few percent of SSD bandwidth for a few minutes, and then quiets down. Neither of these have any effect on other processes on the server - -there is more than one core and plenty of SSD bandwidth.
Ah! This is good to know! Then indeed it shall have no impact.
Mmmm… how? According to the other comment the difference would be that the nodes with slow disks won’t be clogged for 10 min on startup. Not servicing requests instantly for 10 min is not a such a big deal. Or are you talking about nodes where file walker used to take much longer? (hours?) then I agree.
Either way, I’m convinced, I’ll keep defaults I’ll just apply the principle differently: not broken – don’t change defaults
well, not everyone here use ssd and/or multiple cores cpu. One of my nodes running on a poor old hdd with IDE connection and 2 cores old cpu. Lol. About the option, the default one should be suitable for most node operators. In this forum I usually hear people complain about high disk I/O at node boot time, so the default lazy file walker will be good choice.