will it be safe to allocate more space to this node based on my disk utility info presented to me and here
I wouldn’t go beyond 3.6TB
I went 3.5tb and now cli dashboard is reading -3.6 GB and web dashboard -2.28 GB with 76 GB of trash
well storj’s documentation for install of the storagenode recommends a 10% extra free space…
can you go lower… sure… is it safe… well they most likely recommends 10% for good reason, proceed at your node’s peril…
you might not need it 99% of the time… but one day you will hit the 1% or whatever the % is and then it might kill your node… is it worth the risk…?
on a new small node… maybe… less risk vs higher reward…
personally i wouldn’t risk it… i spend 5 months getting this far… and i wouldn’t like to start over for a meek 10% gain… remember your held amount is like 2 months worth of payout until you hit the 15month mark…
so really it comes down to what the odds are… and at best you might gain 5% extra profit… at worst you might loose 20% worth of value on a 10month old node and then you have to start over, get vetted… build up new held amount… so yeah… the risk vs rewards just isn’t worth even considering going above the 10% … imho
but if i’m at 10% or 8% freespace wouldn’t really worry me… ofc it might also be a matter of node size… the larger the node… the longer your responds time might be… stressing the MIGHT
As the precise setting is not yet possible. I was running my nodes extremely full. I had between 2% and 3% of empty space. I would like to have about 5% but it’s not yet possible. Never had any problems with such a small free space allocation. BUT… months are counting and I have same thinking as @SGC new born node it’s not that risky as the old one. So recently I change the settings and now I’m rising the free space up on all older nodes.
But would be very thankful if Storj team could implement the more precise setting for the data. As 1TB node could only have 3% of free space or 13% of free space. Nothing in between because of the rounding.
i’m sort of in the mindset that if we really needed 10% extra free space… why should we get the choice… they might as well just allocate the space and then take as needed… sure that is kinda wasteful… but then nobody would have the option to decide how close to the limit they want to go…
most likely free space is required for some systems and maybe less for others… .not easy to say… but reallly should SNO’s have a choice to kill their node…
it’s like having a button that says overload… warning activating this might destroy your node… some would press it, some wouldn’t …
i know this sounds kinda mega corp like thinking… but why cause more trouble for the storj support team…seems counter intuitive
i mean who benefits… those that doesn’t follow the recommendation, meaning nodes that essentially could be unreliable nodes and storj encouraging not following their own recommendations… it might seem silly, but it quickly could become a slippery slope…
1 Like
You can set 0.9TB without any rounding. I think you’ve done a conversion to TiB somewhere in there that really isn’t necessary. HDD manufacturers use TB and Storj uses TB. So setting 0.9TB on a 1TB HDD would be perfect.
You can also set the node to 867GB if you want to…
That would actually be rounded to 900GB. So it would result in the same thing.
Really? Well that’s weird. Then again, I did not try to specify the space that precisely. Current setting is 14200GB.
It’s not really an issue for pretty much anyone. 500GB HDD’s are too small and there aren’t any common sizes between 500GB and 1TB. And a 1TB node can be set to 0.9TB just fine. So it would only be a problem if you have a rare 750GB HDD at which point, just assign 700GB, close enough. Or maybe if you have a shared space and you have less than 1TB to share or something.
If you set 1Tb drive as 0.9, you will end with 3% of free space only.
Nope, you won’t. You’re still looking at the binary notation size of the disk. 1TB = 1000GB = 931GiB. Most OS’s display sizes in binary units, but they use the decimal notation, which is super annoying. (So your OS might say 931GB, but it’s actually 931GiB)
But both Storj and HDD manufacturers use decimal sizes. So a 1TB HDD is actually almost exactly 1TB and 0.9TB used by Storj would be almost exactly 90%.
Let’s see.
I’ve set now 0.9TB (insted of 800Gb).
So we have 93% free and Dashboard says 37Gb available.
Gues how much of free space there will be after aditional +37Gb 
df -h
/dev/sda1 916G 807G 64G 93% /home/storj
df -H
/dev/sda1 984G 866G 68G 93% /home/storj
Storage Node Dashboard ( Node Version: v1.6.4 )
Available Used
Disk 37.2 GB 0.9 TB
Note that 866 + 68 = 934, not 984.
By default, ext volumes reserve 5% of the capacity for root. The Avail and Use% columns of df’s output are computed after taking this into account. Once Use% reaches 100%, there may still be the reserved 5% free which can only be used by root. The storagenode docker image runs the service as root (against Docker best practices, but I digress…), so it is able to use all of the space on the disk, including the 5% reserved amount.
So, in effect, the output of df is misleading. In your case, the used capacity is actually 88%, not 93%.
(Of course, a nearly-full volume causes excessive fragmentation so it’s advised to leave some headroom not just for the sqlite databases, but also to prevent fragmentation.)
3 Likes
Somehow i think that 5% reservation is for startup disk, so the system would not crash, but not for the data partitions or external disks.
No, the 5% is so that non-root users can’t fill up the disk. When the disk is totally full, even root can’t do certain things. Log files will be truncated and databases may become corrupt.
For example, when a disk is full, you might look for big log files to compress. Well, the compressed output has to be stored somewhere and you don’t want to delete the log file until it’s been compressed, so you need some amount of free space to store the whole compressed log before you can delete the uncompressed log.
This 5% reservation gives root that ability – to use some extra space in the process of freeing up space.
2 Likes
It’s default for any ext filesystem. You can set any percentage of reserved blocks or completely disable it. It’s reasonable to have on small filesystem with rootfs, but for actual data storage it makes no sense and can be disabled.
Ok, so i’ve set 0,9TB for 1TB node. Now the situation is the following. Storj is using 91,8% of disk. This means 8% is free, but 5% out of 8% are locked for the system, so we have only 3% available. Or i’ve made a mistake somewhere?
:~$ sudo df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 916G 841G 29G 97% /home/storj
:~$ sudo df -H
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 984G 903G 31G 97% /home/storj