Hey friends, just wanted to point you to a new document that it looks like we maybe haven’t discussed here: https://review.dev.storj.io/c/storj/storj/+/9978/ The goal of this design doc is twofold - accelerate the performance of object deletion as seen by customers (a common customer complaint), a…

[image] jtolio: When objects are copied, storage node operators will get paid for each copy of relevant pieces their nodes have, even though they only store one copy. Would it be like the said piece being downloaded for a copy to another node? In this case the “Egress” rate would be applied a…

Oh, no, sorry, I should explain more. When objects are “copied” we try to make it an efficient copy. No bytes of the object are actually transfered, but we want to represent that object now in two places as far as the customer can tell. Egress bandwidth payment will remain exactly the same - only p…

[image] jtolio: No bytes of the object are actually transfered, but we want to represent that object now in two places as far as the customer can tell. Thank you. This makes a lot more sense now :slight_smile: So basically that copy (piece) will be treated as per stored ($ per TB) data rate…

[image] jtolio: We’re essentially giving up on having the Satellite try and keep track of how many real copies the storage node has for the sake of simplicity. While I understand the value of simplified code, this sacrifices something that could be a competitive advantage over other S3 provid…

[image] Toyoo: While I understand the value of simplified code, this sacrifices something that could be a competitive advantage over other S3 providers for stuff like cheap snapshots . Though, if this is something that no customer would actually want, then, I guess, it’s a good idea. Oh no no…

Ok, but given you are going to pay node operators more for these snapshots, I assume you will need to pass this cost to customers as well, right?

Oh I see what you mean - yes, the customer invoicing will treat both copies separately. I misunderstood what you meant by “cheap.” You’re right, that’s another tradeoff.

I noticed this first on the changelog and already responded there. My main concern with this would be that this concentrates all deletes in massive IO spikes on the storage node end. The lazy file walker will help in some occasions, but it doesn’t actually work on all IO schedulers. I fear this coul…

You are right that these are concerns, though we’re hopeful that in practice, some of these concerns will be offset by the other tradeoffs (node operators getting paid for each Satellite-side copy, instead of just once, etc). Ultimately, I think the approach we’re hoping to take is to continue to i…

[image] Massive reads on startup troubleshooting This should absolutely not be hard-coded and rather run when it is appropriate over the course of a day. As I have suggested, if the files that get moved into trash get stored in a database with their modification times, any…

Design draft: fixing deletes and server side copy

Product Discussions design draft

jammerdan June 24, 2023, 3:24am 11