Redundant Data on the Asset Server

I am doing a college report about different methods specific companies use for dealing with redundant data. I was curious what Second Life does to deal with redundant data on the asset server where relatively uncontrolled users can make needless redundant data constantly.

I'll inquire with our Operations dept. about this, Rob.

I suppose it depends on what you mean by "redundant" data; in general, we don't worry if every new resident makes their own shiny new plywood cube. If two residents create the same object it just doesn't consume enough space to matter. Every asset is identified uniquely; if 3 prims use the same texture, that texture is only stored once. We don't do anything special if you, your brother, and your friend all create the same plywood cube seperately; that results in 3 objects being created, but as I said; they are small.

So I guess the answer to your question is "Linden Lab just stores all of the data that the residents create, whether or not it's redudant."

Probably not going to help you much on your paper, but there you go.

One could envision a compressed filesystem which stores this data efficiently (this sort of thing is commonly used for backups) but so far this hasn't been appealing for such a performance-intensive system.

So I guess the real answer is, we don't deal with redundant data.

However, you assert that users can "make needless redundant data constantly" - this is true, but there are limits. Almost all asset sources which aren't directly throttled by the system require someone to at least press a button for each asset... and people can only press buttons so fast. If the libsecondlife folks start writing software that gens up new notecards in an automatic way... then we have more of a problem, which we'll have to solve through additional server-side limitations.