Nodes shrinking

Hi there!
This is a request to the Storj Owners, not other Storj Node Operators.
I had 4 nodes on a single IP and 2 nodes on another IP. I already “dismissed” 1 node on the 4 node IP, because it makes no sense keeping it. All nodes were deployed at a time when it was reasonable to deploy another node, because storage data was increasing and I had no more space.
I now realize I shouldn’t have deployed the new nodes, but I didn’t know it back then, and I couldn’t have known. My point is “I had the right to know!”. Also, I believe I have the right to know how much more storage space my nodes will shrink, so I can decide whether to “dismiss” more nodes and save some energy costs that will NEVER be recovered.
So, that’s my request. I want to know, approximately, how much more my nodes will shrink. I can re-deploy nodes in case data inlet increases (real data!). But right now, I need to know how much data-outlet I will face.

Tx.

1 Like

I believe that this is not predictable, as it depends on what the customer uploads. So, there’s no crystal ball. You’ll probably have to decide that.

I’ve set up my node as a hard drive pool where I can simply remove and add hard drives while it’s running. Even if a hard drive fails, the entire node remains functional. Currently, I receive about 2TB of data per month, and with deletions, it’s around 1 TB. However, I must say that I have an almost 99.99% online quote, and audit and suspension are at 100%.

1 Like

They already released the Progress of the cleanup here:

But how much exactly you will loss, nobody can tell.

3 Likes

Well, I didn’t see that… good to know less than 10% will be deleted.
Of course it’s impossible to know how much I will loose. All I wanted was an estimative. If it were 50%, I would dismiss 1 or 2 more nodes…

Explain how is some money worse than no money? Now are you running your server and paying 100% for electricity, without storj chipping in, however small and insignificant that amount is, (and are not getting satisfaction of helping keep the carbon footprint lower, if you are into that sort of things)

Why not? I run multiple nodes per server, so when I need space back I can destroy some of them, to reclaim some space, not all space at once.

Anywhere from 0 to 100%.

2 Likes

Keep it simple: every month after a payout, ask “Is this worth doing for one more month, or not?”. Decide yourself, month-by-month.

Customers decide what to upload and what to delete: Storj can’t tell you what they’ll do.

2 Likes

Since you asked…
2 of my “4-node-IP” (now “3-node-IP”) nodes are running in a NAS that would be running whether I run storj nodes or not. They run in a dedicated, separated (from my personal volumes) disk. In order to justify running these 2 nodes, all I need is for them to generate more income than the electricity that this separate disk consumes. They do, at least for the moment, so, I never thought about stopping them.
A third node that runs in the same NAS is on another separated disk. This node is getting near the “electricity consumption” frontier. If I can preview it will increase, I’ll keep it. If I preview it will continue to shrink, I’ll stop it.
The 4th node (already dismissed!) used to run on a USB cage, connected to the same NAS. It was deployed when the other three were full and I was expecting to get more data in. It NEVER covered electricity costs because it started shrinking after getting up to 1TB. If it had continued to grow as expected, it would have started to generate profit. If I knew then that it would never generate profit, I wouldn’t have started it. If I expect it to generate profit, I will start it again.
Then, to explicitly answer your question, “some money” minus electricity costs is worse than “no money” minus zero electricity costs, whenever “some money” is less than electricity costs and the node keeps shrinking.
I posted this question in order to know if it would be better for me to dismiss the third node, because all of them are loosing data right now, and the 3th node has been idling on getting new data. I set the limit on this 3th node to 2 TB (it used to be more than 3TB) because the other 2 nodes also keep shrinking… so, I wanted to know if it would be better to turn off the 3th node also…

I do hope my answer satisfies you more than yours satisfied me (zero!).

Txs anyway.

Of course shut down the extra disks! It makes no sense to run hardware just for storj.

That’s because you are wasting energy for storj. Don’t. Run storj on your man array if you have extra space, the one that is spinning anyway.

And if your access pattern allows disks to hibernate for most of the day — don’t run storj there either.

Your mindset to attempt to make profit running nodes is a culprit. It’s impossible. If it made sense storj would not need you. They would run nodes themselves.

So no, it’s not a project you plan for and analyze cash flow. It’s “add storj and get something vs not add storj and get nothing”.

And then, the whole idea behind storj is to avoid bringing new capacity online. That’s the core selling feature. And you are doing exactly the opposite.

If your goals are not aligned with the projects’ — you can’t sustainably win.

2 Likes

No!!!
Whenever I start a new node, it’s a project that I need to envision for many months, maybe years. Whenever I start a new node, I use a new disk. It will necessarily not cover electricity costs at the beginning, but if I can preview it will keep growing at an enough rate, then it might be worth it. But if Storj throws me another curve ball (and I have seen enough of them!), then it might never be worth it for the foreseeable future, which is exactly what happened.

I started doing exactly that, and I do have the extra space on my personal volumes disks. But I’m running a Synology NAS. I need to run my personal volumes in BTRFS, otherwise I don’t have VM’s, which I need. Therefore, I had to transfer the nodes to a dedicated EXT4 disk (because running them in BTRFS was ruining my NAS experience!).

You are right!!!
That is why I posted the question. I needed to determine if I should shutdown the 3th node…

As a fellow former Synology user I can fully appreciate that. I presume you have tried adding a lot of ram and SSD for metadata and it still did not help? (Btw, don’t hesitate to join to the dark size TrueNAS users community who barely notice node even being there)

Well, I certainly didn’t add RAM for the storj cause. I did add an SSD, which died just before warranty due to too much use…
I can’t go the TrueNAS avenue right now. I’m in too deep on Synology. And, as I’m certain you understand, I can’t change anything hardware wise because of storj. I either run nodes or stop them. No hardware investment could ever make sense…
I only run storj nodes because I have extra disks. Whenever they die, the nodes die with them…

I don’t know how to put this nicely: “You’re doing it wrong” :wink:

I say that in jest… but Storj should only ever be using extra space… on a disk you’re keeping online for other reasons. It should never be the only app using a drive.

I understand if you don’t think it’s worth it. But even if you graceful-exit: you should still check on the project a couple times per year to see what’s going on. Maybe you’ll come back! :smiling_face_with_three_hearts:

1 Like

Yes… but when I moved my 2 nodes that were running in my ever spinning disks to a new separated disk, I already had 10TB. So, those 10TB used to cover the cost of running a dedicated disk for storj. Now, I’m trying to figure out the future…

Of course not. But you could have added it for the benefit of your users – the nas (if implemented correctly, I don’t know, I jumped the ship before they fixed broken SSD cache, let alone introduced metadata caching) should become much more snappier. As a side effect this would have made running storagenode possible. But only as a side effect. The primary goal is to improve user experience. You’ll be surprised (I sure was) how much difference a pair of used $10 enterprise SSDs off of eBay can make (under the right circumstances). If I did not put disks there myself I would have though I have full flash server :slight_smile:

This tells me three things happened here:

  • it was a consumer SSD. They are notoriously garbage
  • The sector size wasn’t manually adjusted, most consumer SSD report 512byte sector size. It’s a fiction. If not corrected to 4k when adding to array this results in orders of magninture write amplification
  • SSD was too small (or at least smaller than amount of metadata) resulting in frequent rewrites. Note, this alone would not be a problem, enterprise SSD can withstand multiple daily rewrites for decades, but coupled with above two issues probably was what resulted in premature wear.

One day I woke up, said enough is enough, and posted 6 Synology boxes on eBay. Best decision I have ever made.

Correct. Do it for your sanity and for your users. Friends don’t let friends to continue suffering remaining in Synology ecosystem. Then consider storj to offset costs, after your users are happy and you did not touch your nas for years, because it’s working perfectly, and your hands are itching with what else to do with it :slight_smile:

1 Like

For future readers, Storjlings likely will not post predictions (except obvious ones like that: Storagenode suspended, but has been online for the last few weeks - #11 by Alexey), we could post our plans, like the latest one Data Cleanup Plan - Update, however it may not help you.
I would suggest to consider for yourself, but @arrogantrabbit is right - you shouldn’t run a node on the hardware dedicated to Storj - the ROI could never happen, it’s better to run on the hardware which will be online with Storj or without, then it would be a nice discount to your already paid bills. The last statement is a key.

2 Likes

Here’s the answer, straight up. Stop the node. The mental energy you’ve already spent and the advice sought is a trivial insult to your time, and ours. For a $3 monthly pay cheque? WTF? Move the node to your main array, cap it’s activity or exit it. Reserve the hdd as future spare.

1/16th of a cent,
Julio

4 Likes

+1 Julio! We have a very helpful community. If a SNO has any concerns, over 28000 other nodes stand ready to assist: and reduce their burden by holding the pieces instead.

Just trying to help!

1 Like

You realize the nodes start with zero storage, right?
I started this node when all the others were full. For sure, since I was paying for the electricity cost of running a new disk, there could not be ROI. But I expected the node to grow up to a point it would make sense running it and compensate for the months it would take to grow enough. And it did!!!
Now that it has shrunk a lot, mainly because I caped it in order to minimize the shrinking of the main nodes, I wanted to know if it would be worth to keep it. For that, I needed an estimate of the storage space that would vanish. Also, if I had known an estimate of the vanishing storage at the time I started it, I wouldn’t have started it.
But the decision to stop it now is not so simple. If the vanishing storage stops, the other nodes will fill up and it will make sense to restart again another node. But that node will start at zero storage and will take a long time to vet. This one has 2TB and is vetted.
The hdd has no use as a spare.

There’s a deletion going on that has little to do with what customers decide… and it’s not hard for storj to estimate how much…
You’ve been very helpful… keep it up!

1 Like