Well, 10% is actually more necessary on smaller nodes than bigger nodes.
I actually keep 7% with a maximum of 500GB (for nodes >7TB). But Iāve even got nodes like yours, where the filewalker apparently sucks. On those even as few as 500GB has been left, without any noticable negative impact on the node itself thoug. Althoug, Iāve to start them with storage2.monitor.minimum-disk-space=100MB as a setting, since they wonāt start otherwise.
Storj displays the space as TB (same as drive manufacturers) while the Windows displays it as TiB, despite the unit of size is displayed as TB.
12.7 TiB is roughly 14TB, so I would say you can go ahead and set the node to 13TB for now and change the settings slightly again once the node will be full and drive wont.
Everything is correct. Windows shows space in binary units, our software uses SI (decimal) units.
But the difference between used space and average disk usage is not ok, likely the filewalker and/or the Garbage Collector didnāt finish their job.
@moudar Please search for FATAL errors in your logs, also errors related to the filewalker (search for ERROR or failed and walk) and the Garbage Collector (search for ERROR or failed and retain).
For Windows and PowerShell:
It would be much simpler if the node code allowed for more than 1 mount point/directory to be used as data storage. Expanding a node then would become easy and enable a lot better utilization of disks.
Adding to the above what would then be just brilliant, would be if one mount point (disk) failed and the node just kept running on the remain mount point and remove the failed disk data from the node. Perhaps a future feature.
Itās a very bad idea to re-implement a bad RAID0 solution, where with the one disk failure the whole node is lost.
You may do so from your OS though, but the result will be the same.
So, itās much better to run 2 nodes instead, each on own disk.
I think unique means the Code to adapt multiple mountpoints as multiple nodes,
So if a āsecondā data place is given, generating the corresponding āSub-node-idā with its own Reputation.
Ability to move data including the identity to new mountpoints editing the path, or giving the command to do so would be a verry good way to make multi nodes maschines more manageable.
Or developing the Win GUI Storj Node Toolbox from vadim( i think.) to adapt to be more flexible.
(i canāt use it because of nostandard installation path of the first node)
If it has an own NodeID for the second disk, this will be exactly the second node.
And you may already to do so, generate a second identity, sign it with a new authorization token and run it with the second disk.
Then you may add both nodes to the multinode dashboard.
Yes, i agree. Edit: It was not clear enough.
But generaly an easyer adoption of expanding single nodes on windows pcs to multi nodes is maybe in the far away future more interesting, when more expanding is needed again.
I strongly disagree to have any simplifications in running of multiple nodes.
We need durable nodes, not a high nodes churn rate. Simplification always attract users who want Wizards - ānext-next-done. Oops, doesnāt work something - destroy. next-next-doneā¦ does not work again and I do not care why, I have bunch of disks and want to put them into work after I failed with HDD-mining. Hey support - why is your software does not work?!ā
See I would like to enquire: When will I receive my commission?