Just for some clarity, forgive this long post:
“Total of 100MB cap per client account” isn’t maybe the best way to state the current cap. It’s actually “Total of 100 PUT operations per client account(not POST or DELETE or GET)” This is where its set in code
Now why I’m stating this as a difference is cos, say when you create an account, that translates to 1 PUT of StructuredData and this is tiny (well SD itself can only get to 100KB before it gets broken down further). Now if the client goes onto creating 99 more SD even at max size of 100KB, after this point they would be getting LowBalance error. In this scenario they’d have only stored roughly 10MB before hitting the cap. If the 99 PUT of SD was smaller, then the total would ofc be much smaller than even this 10MB could even be a few KB.
Now with ImmutableData, we got SelfEncryption in play, so say we created an account which made us store a SD and then we upload a single 98MB file, we know with the current MaxChunkSize set at 1MB we’ll get 98 Immutable Data chunks and 1 SD DataMap which each need a PUT operation in the network. Now this would all succeed and PUT operations past this would start failing with the same LowBalance error. In this case however we would have stored about 98MB + tiny bytes of account SD + DataMap SD before reaching the client cap.
Now these are extreme cases, in reality add in folders(not just ones created by user but also stuff like root directory listing and app sandbox folders and then yes ofc folders created by client apps)/dns-records/public-id and we got more SD we store at varying sizes but factors into the PUT operation count. similarly for SelfEncryption if the file we’re storing is between the MinChunkSize and MaxChunkSize we’ll still end up with 3 ImmutableData chunks and thereby 3 PUT operations. less than MinChunkSize does some more funky stuff but should result in just 1 PUT operation I’d think.
Overall, the number of PUT operations don’t hold a strong bearing on size and can change based on the use-case. Before we go into the “Then why use PUT operations to limit client storage?” discussions, Worth of-course noting this is merely a current test feature. When Safecoin features are implemented, that’d be serving as the limiting factor to check if a client storage operation can be allowed or not instead of some magic number being set in code.
Saying this, for now while we don’t have Safecoin implemented in code, I think @Krishna_Kumar is looking at some options to present a visual status in Launcher of how close an account is getting to it’s storage cap(with safecoin it can still serve the same purpose in a different way based on safecoin availability with the account). This info also needs a “small” amount of work in Vault code to return that info to clients which it currently doesn’t yet do. So that hopefully helps a bit than having to calculate the number of PUT operations we’ve done so far in some other way like grep "Sending PUT Request" Client.log | wc -l 