3 unrelated questions

  1. Why don’t I have any control over the node version?
    I’m on a synology. I run the obligatory watchtower. I stop, remove the node and pull the latest version in a SSH session whenever I need. When I restart the node I realize the new version can be the actual latest, the same version that was running or even an older version than the one that was running before I stopped the node…

  2. Why just “lazy filewalker” option? Why not a “really fu__ing lazy filewalker” option?
    My disks noise have been driving me crazy since 24 hours ago…
    When will they stop scratching?
    I’m talking about a 7.5, a 4.5 TB and a 3.5TB nodes on EXT4 disks reporting 100% usage and thousands of IO reading operations.

  3. Why doesn’t storj keep a reasonable amount of tokens in Binance in order to pay SNO’s with zero fees?
    My pay address is a layer 1 in Binance. I’m sure many SNO’s do the exact same as I do. They keep away from the ZK nosense and hold a layer 1 address in Binance…
    For f___s sake just do the math…

You can disable automatic updates and do them yourself. Some of the largest SNOs do this.

Lazy just means low-priority: the same amount of work needs to eventually get done. And it sounds like you’re talking about the used-space filewalker: if the downsides don’t deter you… you can just disable it and it won’t run on node startup anymore. Peace and quiet! :wink:

Since we’re just making stuff up with no proof: I’d say most SNOs aren’t using Binance payout addresses (this community seems big on “not your keys, not your crypto”). Should they add the overhead of managing coins on every large exchange in the hopes a couple wallets are local? Sounds like a waste of time.

2 Likes

Eeeeehhhh… I’m not so sure about it. It’s a nice sentiment in the vacuum, but in the real life using exchange address is simply easier. And storj does not exactly play seven figures to worry about things like these. So I’d say " a vocal minority of users made it clear in no uncertain terms that anyone who uses non-custodial wallet is doomed to homelessness and despair". Others just use exchanges, because division of labour is what let us rise above apes.

2 Likes

I said “I stop, remove the node and pull the latest version in a SSH session whenever I need.”
I guess I’m doing some of the updates myself… and that’s when it goes wrong. The watchtower always updates to the real latest version…

I didn’t know that. How do I disable it?
But if I disable it, when will it do its work?
And if it does its work somewhen, will it be the same annoyance?

When and how will “most SNOs” ever change their tokens? (there’s no global storj token economics!).
I’m guessing someday they will have to stop owning their tokens and transfer it to an exchange…
There aren’t many “large exchanges” around…
Sounds like a waste of money…

You’re funny, man… :grin:

In general, Storj Labs doesn’t do anything with the tokens in order to avoid the legal confusion that is cryptocurrency in the US. Providing liquidity and that kind of thing might be an issue, and until the laws actually determine whether crypto is a currency, commodity, or security the company tends to avoid any actions with the token including even discussing it.

1 Like

Alrighty… let’s not discuss it. Just keep paying the layer 1 fees in order to pay me. It doesn’t make much difference to me getting paid every month or every 2 or 3 months. One thing’s for sure, I will never opt into the ZK thing…

1 Like

And that’s fine. We pay out a 3% bonus to help offset fees with Zk, but if you don’t want to participate, that is no problem. I do understand your suggestion, but we provide the bonus to help with that offset. And payouts are more regular. If that doesn’t work for you we provide the L1 payout.

2 Likes

Uncomment the storage2.piece-scan-on-startup flag in the config.yaml and set it to false.

It won’t. You risk having the dashboard’s reported used space (for both real data and trash data) going out of sync with reality. But if your filewalkers for garbage collection are completing without error this shouldn’t be that big of a deal (these run once a week anyways and you cannot avoid them unless you just want to carry trashed data in exchange for peace and quiet).

1 Like

Brooo… how about NOW? You should be gratefull, its not firewalks, currently we are noting the highest users usage burst, hope it can last month like that now, means faster HDDs filling!1

NOW? They’re still making too much noise and somewhat diminishing my synology performance overall… storj nodes were never its purpose…
I don’t really care about large traffic. I have no more HDD’s to fill. I’m full…
In other times I could consider buying another HDD. NOW, it would be stupid…

Just noticed I already had done this somewhen… but I made a mistake and wrote “storage1.piece-scan-on-startup: false” instead of storage2… :flushed:

U mad, bro?
have You tried some soundproofing?
im fortunate enough to have good sound proof case for my PC, and i m familiar with this technology as well:

yeah… well, noise is not the only problem.
I have other stuff running in the NAS that get really hurt when the CPU IO wait is 80 to 100%, even though they run in different disks…

Not anymore :slight_smile:
We implemented an updater inside the container. So it will download and install the freshest version allowed for your NodeID independently of your forces.
However, the watchtower is still useful - if we update a base image, it will be updated automatically too. This happen not so often, because the base image contains only OS and a supervisor.

1 Like

Then perhaps you need to add a cache device to the pool, or migrate to ext4. BTRFS is known as a not good FS for Storagenode: Topics tagged btrfs

I said “EXT4 disks”.
I do have nvme “cache”. I use it as a disk to hold DB’s, including storj DB’s and also the storj logs. The storj logs is the usual reason for me to restart the nodes. They get too big.
I once had a nvme working as actual cache in the synology. It was killed by the storj nodes before the warranty expired (too many W operations).
Also, I don’t see how cache would help the filewalker. If I understand correctly, the filewalker is reading all the files in the node…

You may use this:

Yes. But if you didn’t disable a used space filewalker on start (it’s enabled by default), all metadata will be cached and the next filewalkers should take much less time.