Relationship between Lazy Filewalker and piece-scan-on-startup, explanations of settings

[ad329]

I was reading some of the forums relating to the new Badger DB stuff and saw these two items come up.

Had a couple questions in regards to this, people said that lazy-filewalker setting and piece-scan-on-startup setting are related to eachother, for example piece-scan-on-startup must be disabled for lazy filewalker to work.

I was wondering why this is the case, what the behavior difference is between lazy-filewalker being on or off? I was thinking its only controlling the IO priority of the file walker process, there are no other differences?

What is the piece-scan-on-startup for in this case, is it just an extra scan that is done before starting the node? it seems like the filewalkers still run continuously regardless of this setting.

Additionally, was wondering how the badger cache works, I thought that for the lazy-filewalker we had to continually scan the files to ensure that the metadata/hash matches with what is expected. if we are caching this data, aren’t we loosing the “continual check” aspect of this? What is the TTL on the badger cache, and how much disk IOdoes this actually save?

[jammerdan]

@ad329

for example piece-scan-on-startup must be disabled for lazy filewalker to work.

No. Scan on startup and lazy filewalker can be enabled at the same time.

You cannot enable the badger cacher together with lazy filewalker.

@ad329

What is the piece-scan-on-startup for in this case, is it just an extra scan that is done before starting the node?

Filewalker status

Logs should be at least info level Used space filewalker Task: Calculates disk usage by scanning all pieces and updates the local node databases afterwards with these values docker logs storagenode -f 2>&1 | grep "used-space-filewalker" | grep -E "started|finished" GC filewalker Task: Based on a Bloom filter it marks pieces as expired for removal by the retain process docker logs storagenode -f 2>&1 | grep "gc-filewalker" | grep -E "started|finished" Trash-cleanup filewalker Task: Deletes p…

[ad329]

Thanks, this was helpful. However it still doesn’t answer my question of what “piece-scan-on-startup” is for, and why would i want to turn that on?

Also, why doesn’t badger cache work with lazy filewalker. And also

What the behavior difference is between lazy-filewalker being on or off? I was thinking its only controlling the IO priority of the file walker process, there are no other differences?

[jammerdan]

@ad329

However it still doesn’t answer my question of what “piece-scan-on-startup” is for, and why would i want to turn that on?

It does:

Calculates disk usage by scanning all pieces and updates the local node databases afterwards with these values

Normally the node should track every upload and deletion sizes and update the nodes databases accordingly. But this does not always work without issues as the database can become corrupted or locked while it wants to update a value. So a full scan is required from time to time have that corrected. This setting enables or disables this scan on every startup.

@ad329

Also, why doesn’t badger cache work with lazy filewalker.

Badger cache: are we ready?

Because it needs the cache exclusively. The lazy filewalker spawns a new process and there is no guarantee that only one is active. A TTL cleanup would spawn while garbage collection is active and that’s game over for the badger cache.

[Alexey]

@ad329

I was wondering why this is the case, what the behavior difference is between lazy-filewalker being on or off? I was thinking its only controlling the IO priority of the file walker process, there are no other differences?

What is Your IOPS with no ingress but during filewalking?

People are greatly misunderstanding how IO priorities work. I’ve explained it before, but I’ll have another go. Normal filewalker: “Gimme gimme gimme gimme!!!”. Uses up all of the disk’s IOPS, numbers go up => it must be great!. No IOPS left for the actual storagenode => lower ingress => less stored data. Your disk simply isn’t fast enough and loses races. Lazy filewalker: “Can I please read some data from the disk?” Host system prioritizes from high priority (actual storagenode process) to lo…