Will filewalker ever finish?

Node Operators troubleshooting
,
1

Hey - im helping a friend that has a very new node - less than 1 month old.

we got some discrepency with the storage used on dashboard vs windows. anyways its and issue talked about alot.

we got db and logs on SSD.

the disk has a constant 100% usage.
lazy mode is enabled.
the “average” disk read the past like 10 miuntes is about 0.5MB/s - Really slow.

The drive is filled with 5.77TB

At this rate filewalker will take about 140 days…

Am i missing something? not much data is coming in today so you whould think lazy filewalker can go a bit faster?
and before you ask - no nothing is wrong with the disk.
The disk is NTFS
the dashboard showes like only 1.22TB used

So i know my friend will be payed for at actual data that is paid - no problem. but i want to show him how much he has of used space - so this is kinda a bummer on a brand new node.
Now also keep in mind nodes have to restart some times to update and stuff :wink:
Version is 1.107.3
is the “resumed” filewalker implemented yet?
And i know average will most likely be higher and it will take more like 10-20 days - but still. a long time.

The disk is 12TB.
the disk is on a lonely subnet.
16GB of ram and i5 8400
All should be good to get a faster filewalker - but its slow :smiley:
Thanks in advance guys :slight_smile:

2

The filewalker only reads metadata, not the contents. It does take awhile still, due to the sheer number of pieces and the couple IOPs per piece.

This past week we’ve also seen three bloom filters from SLC so your node may be backlogged.

2 Likes
3

Makes sense - so i should rather compare the read speed to the meta data’s size.

4

I recently moved from Windows GUI to Docker (Ubuntu 24.04), due to human error on my part when editing the Storage Space. On the same hardware, with now roughly the same space used (maybe different type of data, keep that in mind!) I could tell that the filewalker finished much faster. Read speed is in the range 10-15 MB/s instead of 0,5-2 MB/s in Windows.

There are some best practices for reducing I/O load in Windows, like excluding the drive from Defender and disabling search indexing each file on the drive. The latter should be disabled at the start, since disabling it afterwards will cause every file to be processed again (a multi-monthly job).

1 Like
5

Thanks for the reply - i dont think i have dissabled file indexing on the drive.
That might be a solution but you say i cant do it here afterward the node has been up for weeks?

Its weird there is SUCH a big difference from docker to windows…

6

No, I sad that disabling it afterwards will mean that Windows has to remove the search index information for every file on the drive (its stored as metadata). Meaning that on top of the already running filewalker, Windows itself is - ironically - filewalking for itself. Slow on top of slow as I experienced, not worth the time. Just my own opinion.

1 Like
7

But, is it then not smart to just do it, dissable file Indexing once and for all and just let Windows do its thing, to then in return hope filewalker kan speed up?

8

I had a 7TB node on a fragmented ext four drive and the used space filewalker took around 10 days.

it was indeed very slow.

9

Yes, correct just totally disable indexing in windows - who uses it anyways? No need to go back and de-flag the meta for every node piece existing on the disk, that’s just as useless as de-flagging 8.3 filenames, if somehow - by some miracle they were ever created (deprecated to only system drive since Win 8)

2 cents

10

Was this human error “by mistake I installed Ubuntu instead of Windows”?

11

That would not be classified as a mistake. Apart from maybe one’s personal taste in distros.

2 Likes
12

Probably using a Resource Monitor could help better, filter used files for the storagenode.exe and track what is subfolder in blobs it’s currently scan. It scans them in the alphabetical order.