yes, and no. Windows and NTFS are a bad guys here… Initially the NTFS (IPFS in the past) was a good filesystem against FAT, but later much more efficient FSs were implemented.
However, back to the topic. If you do not plan to migrate (and this is OK), you likely need to tune it to be more fast than now.
It’s already doing so, it’s called a “lazy filewalker” and regulated by the option pieces.enable-lazy-filewalker (it’s true by default). This option affects almost any filewalkers (except “collector” I believe), so they run with a lowest possible priority.
You do not need to touch the parameter, which would directly affect your payout (lower value - less uploads and download requests = less payout), it also abruptly affects customers (they will receive a response “that node is overloaded, it’s too busy to provide you a piece which you pay for”), so it is better to do not change it from a default (0, i.e. no limits). Especially after the “choice of n” is implemented:
which again suggests that you have issues with a disk subsystem. The RAM always grow if the disk is not able to keep up.
How is it connected? What’s filesystem? How much RAM do you have?
exactly. Except that docker is not a virtualization, it’s actually running on the host, moreover - on the same kernel, but with restrictions. So no penalties unlike any virtualization (independently how good is it).