You just did… the trash walker in always on, no matter how you set lazzy and used space fw.
2 Likes
How often does it run then? I thought it was daily, but it’s been like 4 or 5 days since I disabled filewalker in the startup command, and I haven’t seen the trash one since.
If this is the one that runs weekly and actually empties the trash, then all’s good.
trashman filewalker runs once a week,
its triggered by famous Bloom filers sent from Storj satellites (see other topis, its fascinating)
beside that i belive trash folder is being dumped daily if something older than 7 days is detected, but thats just quick action.
You cand find it in the log - info level; grep “pieces:trash”.
I can’t check right now, but it runs once per 12 or 24h for each satellite. I believe it’s 24h.
This empties trash directories older than 7 days.
The Bloom Filter triggers Garbage Collection FW that moves pieces to trash, to be deleted afer 7 days. It greps as “retain”.
There is the “collector” also that moves pieces to trash or deletes them - pieces that have an expiration time set by user. It runs hourly.
I don’t know how to grep other walkers, because I disabled logging of piecestore and I believe it filters out some walkers too.
You can see most of the walkers trigger time in the config.yaml.
Alexey or BS can correct me, because they understand better the processes.
1 Like
Yes, because it’s run in a lower priority. When the node has a more high IO priority (like a request from the customer), all “lazy” load will stop to give a more priority to the actual IO process.
I just state, that extension cards are different. Some built to be as cheap as possible. They works, of course, otherwise nobody buy them, right? But usually in expense of do this properly. In this case they took the usual bus and split it as much as possible. However, each lane will be only a fractal of a possible bus speed… thus a low performance and the higher latency. Nothing is free, right?
You should, unless you also disabled a lazy mode. In some cases the not-lazy filewalker may not log anything on info log level, this is perhaps a bug though.
every 24h since the start date. It’s a hardcoded interval.
Unfortunately, you are not correct. They are different chores.
The garbage collector and the retain process are definitely related to a Bloom Filter sent from the satellites, and they are sent at least once a week.
However, the trash filewalker is running independently of these ones, it’s simple run every 24h since the node start.
I’ll say it once again: a proper operations manual would be so useful. We keep explaining the same thing again and again.
2 Likes
Yes, but I do not know how to keep it updated. Even my small topic how to catch all filewalkers from the log has become outdated in a few weeks. So I made it a wiki:
File walkers weren’t changed for, I think, two years. But yeah, it takes time to keep it updated. It would still be less time than answering the same questions again and again.
2 Likes
There are certain SATA cards that are just controllers (ie no different than your motherboard onboard ports). Example boards based on ASM1166 (6 port cards). You can safely use these for storj.
Other cards have a port multiplier on top of the controller. Example boards with Marvell 88SE9215+JMB575 (8 port cards). 88SE9215 is the controller, JBM575 is the port multiplier. You should avoid these for storj. They are typically used for workloads that don’t require a separate “line” (sata interface) to each drive. If the workload is low, you can split a single interface to a couple of drives.
With regards to running baremetal Linux:
- one node per drive
- storj drives formatted as ext4 with no lvm
- use an SSD for the OS (can have the databases on it as well)
- stuff as much RAM as you can afford (er sorry, have laying around). Some RAM should be left for OS+buffers+cache, so just because you “only” need 1GB per node under normal usage, doesn’t mean you should run 16 nodes on 16GB.
- setup proper services for the node (ie systemd)
- skip storagenode-updater and keep an eye out on version.storj.io for the update cycles
storj drives should be listed in /etc/fstab as:
UUID=(YOUR_PARTITION'S UUID AS SHOWN BY lsblk -o+UUID) /mnt/node1 ext4 defaults,noatime 0 0
If the system restarts abnormally (ie due to power outage), stop node services, unmount the storj drives and manually run fsck on them. Fix, mount -a and restart services. This is a consequence of the last column being a 0 (don’t scan on boot).
Regarding actual config.yaml tuning, I turn on lazy and turn off scan on startup. I only switch on scan when I suspect that the usage reported is deviating far enough from the actual usage. Other than that pretty much vanilla settings.
1 Like