root@sp1:~/safe/images# SN_LOG=all safe --log-output-dest data-dir files upload ubuntu-22.04.3-desktop-amd64.iso
Logging to directory: "/root/.local/share/safe/client/logs"
Using SN_LOG=all
Built with git version: 794fca7 / main / 794fca7
Instantiating a SAFE client...
🔗 Connected to the Network Loaded wallet from "/root/.local/share/safe/client/wallet" with balance Token(199999999788)
Preparing (chunking) files at 'ubuntu-22.04.3-desktop-amd64.iso'...
Killed
That looks like an Out Of Memory (OOM) error. We need to have self encryption stream rather than do the whole file at once. In the meantime perhaps try splitting the file until it works. A PITA but it’s telling us to get the client fixed really
root@sp1:~/safe/images/ubuntu# SN_LOG=all safe --log-output-dest data-dir files upload ./
Logging to directory: "/root/.local/share/safe/client/logs"
Using SN_LOG=all
Built with git version: 794fca7 / main / 794fca7
Instantiating a SAFE client...
🔗 Connected to the Network Loaded wallet from "/root/.local/share/safe/client/wallet" with balance Token(199999999772)
Preparing (chunking) files at './'...
Making payment for 10120 Chunks that belong to 191 file/s.
Error: Transfer error Not enough balance, 199.999999772 available, 18446744073.709531376 required
Caused by:
Not enough balance, 199.999999772 available, 18446744073.709531376 required
Location:
sn_cli/src/subcommands/wallet.rs:305:26
It’s actually good and getting much more real life like now. The days of throwing any old data at these is changing to folk saying what would I really like to store and how much will I pay. We are trying to get to testing economics and with free space and free coins it’s really hard, but it is getting closer to reality I feel.
The crunch will be the transition of a free playground to a safe secure store for personal data we want secured and perpetual. That means we need the economic incentives to work out and that’s where we are circling here, baby steps, but steps never the less.
There’s a looot of pending improvements to the client and dbc setup that will reduce this. Right now we keep a lot of clones of created DBCs/transactions in mem for no good reason. This is a greater cost to us than self-encryption at the moment (i was suprised; i mean, there is a self-encyrption cost/peak for sure. But for even a small number of files the DBC overhead is wild!). So there’s a big batch of changes coming, and there’ll be more as we streamline to using/sending utxos.
Do we have a way to share the addresses of our uploads via the network?
I could for example upload a text file with information about other uploads, but could that text file be edited by others, so that they could add their uploads?
This question have no definitive answer for many years.
It was theoretically possible with previous versions, but in practice there were problems with scalability and reliability.
Having precise answer to this question will also allow to predict how useful Safe Network can be.
Another thing to account for is that with added economics part, network became slower → throwing lots of data became harder.
I think some sort of faucet is needed, or at least someone needs to have some SNT to start the first upload. Otherwise no one has money to upload, so no one can earn by running a node. Chicken, egg.
I think it will be a tricky balance but easily tweaked.
Too hard to participate and people won’t join test networks. Too easy and your tests aren’t realistic.
My guess is we need to go gently. Not many of the testers can run nodes yet, so we lose many uploaders and we make it hard to try out.
The network can’t bootstrap without a ‘free money’ phase (MAID → SNT) anyway, so testing that is also valid, using a faucet. Once that is sound I think it’s when we shift the dial by turning the faucet down, but probably not off until launch.
Why keep the faucet around at all? To allow newcomers to kick the tires and help get the word out. Telling someone they need to run a test node for a week before they can play will be like slamming the door in people’s faces.
After launch I think it will still benefit the project to have SNT giveaways so people find it easy to try out and get on board. Like stabilisers (training wheels) on a bike, remove them too soon and .
Tried to download again same files I uploaded last night (all uploaded successfully by the response). Last night when I tried I was able to download 9 of the 11; but tonight only was able to retrieve 4 of the 11.
The same error as last night, couldn’t retrieve all of the chunks.
I’m curious what happens when it fails to get a chunk, does it try from another node (assuming there are 5 copies)? Or is this a timeout error?
Thanks @JPL, there is a change although it isn’t obvious what. I am seeing both the messages I was using and vdash is still picking them up, but they no longer seem to be a good measure of GET or PUT.
@joshuef can you comment and maybe suggest a better measure of GET and PUT from logfile messages. I have been using the following but they no longer seem to line up with the record store access:
GET:
trace!("Retrieved record from disk! filename: {filename}");
PUT:
trace!("Wrote record to disk! filename: {filename}");
.