[Opensim-users] Are unused assets deleted?

Fri Aug 31 18:41:43 UTC 2018

No.  All that clutter stays around forever until deleted or until some
catastrophic crash of the asset db :)

On Sun, Aug 12, 2018 at 1:02 PM Luisillo Contepomi <
luisillocontepomi at gmail.com> wrote:

> >I said "I believe"
>
> I've tried it and it seems to work as you explain.
> ;)
>
> 2018-08-12 21:31 GMT+02:00 Haravikk <opensim at haravikk.me>:
> >
> >> On 12 Aug 2018, at 16:58, Ethan A. Gardener <eekee57 at fastmail.fm
> <mailto:eekee57 at fastmail.fm>> wrote:
> >> On Sun, Aug 12, 2018, at 11:03 AM, Haravikk wrote:
> >>>
> >>>> On 12 Aug 2018, at 09:52, Luisillo Contepomi <
> luisillocontepomi at gmail.com <mailto:luisillocontepomi at gmail.com>> wrote:
> >>>>
> >>>> When you build a cube in a region and after you delete de cube will
> >>>> remain in database forever or until you erase it manually
> >>>>
> >>>> Best regards,
> >>>> Luisillo
> >>>
> >>> I don't believe this is quite true; when you create an object in a
> >>> region it exists only within the region where it is located, if you
> >>> "delete" it then it is transferred to your inventory, if you then
> delete
> >>> it from your inventory as well then it should be gone for good.
> >>
> >> You believe, or you know?  In technical fields, the difference can mean
> everything.
> >
> > I know.
> >
> > I said "I believe" because I was trying to give the benefit of the
> doubt, as what Luisillo said can be true, especially of other asset types,
> but isn't always true of objects in particular. It is for possible for a
> cube to never become an asset, for example if the region it is in crashes
> without saving, or is deleted without returning anything to user inventory,
> all such objects simply cease to exist. Any textures applied to those
> objects however would remain in the asset server.
> >
> >>> Using vanilla
> >>> LSL for example it is possible to apply textures, trigger sounds and
> >>> fetch notecards using a GUID.
> >>
> >> Um... this is where I think the OpenSim project should have taken the
> position, "UUIDs alone are unreliable."
> >
> > While I kind of agree, it would mean a pretty big departure from vanilla
> LSL which OpenSim was being made compatible with at the time. I mean you
> could reasonably argue OpenSim should never have tried to support LSL in
> the first place since it's a terrible language that never should have been
> in Second Life either, but what's done is done!
> >
> > That said, I wouldn't say UUIDs are unreliable, just that you need to
> know when it's appropriate to use them; they're fine for non-transferable
> objects so long as the asset exists in an object/user inventory somewhere,
> i.e- you shouldn't use the UUID unless you know where the asset it
> references actually exists, and you shouldn't at all for anything
> transferable that could end up on another grid.
> >
> > Cases where referenced assets have vanished on SL were I think times
> when LL were trying to solve the exact same problem, and hadn't considered
> scripts references at all, but LL and a lack of thought given to scripting
> has been the status quo from day one 😏
> >
> >>> The only way to safely flush out textures, sounds and notecards (and
> >>> animations if you allow GUID fetching of these) would be to scour every
> >>> object, script and notecard on your grid for possible GUIDs, but even
> >>> then this is only safe if you don't allow scripts to contact external
> >>> services (as a user could store GUIDs in an external database for
> >>> example).
> >>
> >> The relatively popular Boehm garbage collector for C and C++ can
> operate in exactly this way, but I'll admit that a grid database is an
> awful lot bigger and slower than the memory of one computer program.
> >
> > Yeah, you'd have to inspect every single script and every script VM in
> every single inventory, object inventory, and in world object inventory in
> every region on a grid, and even then some regions could be offline (e.g-
> OS Grid where you can join or leave at any time). If you're certain that
> you don't need to preserve such items, or the problem is bad enough that
> you don't care to, then it's reasonable to skip such a step; I was just
> trying to highlight why an asset can exist in the asset server without
> existing in an region or inventory, and still be unsafe to delete.
> >
> >>> This is I think why in SecondLife it costs L$10 per upload, as it stops
> >>> users going overboard with uploads, this is also the reason why images
> >>> are stored at limited sizes, sounds and animations are limited in
> length
> >>> etc.
> >>
> >> Hmm.  The upload fee was explained as, "An economy needs sources and
> sinks.  The upload fee is one of the sinks."  They may have had multiple
> reasons, I suppose.  All the other limitations might be explained as trying
> to limit their bandwidth.  Textures have the additional problem of taking
> up memory in the graphics card, a big problem in the early '00s as graphics
> cards had relatively little memory couldn't decompress images on the fly.
> It may still be a problem: a 2GB graphics card can be a big help, but that
> might be some other factor.
> >
> > Sure, it's not the sole reason, but even a price as low as L$10 is a
> deterrent to uploading things excessively. It's essentially the same
> principle as charging 5p for plastic bags to cut down on plastic bag
> pollution, it's not much but it's surprisingly effective.
> >
> >>> At the end of the day though the question is; how limited is your
> >>> storage really? The only cost of unused assets is in a bit of wasted
> >>> hard storage, but storage is pretty cheap, so unless your grid is
> >>> growing beyond your ability to match it then you might be trying to
> >>> solve a problem where the solution could be more destructive than the
> >>> problem itself 😏
> >>
> >> I'm told that by the end of InWorldz, its asset server was growing by a
> terrabyte every month!  There's nothing "more destructive" about trying to
> limit that kind of growth!
> >
> > Is this such a case though?
> >
> > Even so, asset cleaning isn't really going to limit that kind of growth
> much; unless a grid is accumulating a similar amount of unused assets each
> month then at the end of the day you're still talking about a huge volume
> of new assets being the real problem there.
> >
> > At that kind of level though, 1tb a month is 12tb a year, a 12tb hard
> drive is around $400 now. With the right kind of setup it wouldn't cost a
> lot more than that to add storage, or swap older drivers for newer, larger
> ones to keep ahead of it. Not ideal, and you'd better hope someone's
> helping to cover those, and other costs, but it doesn't have to be the end
> of the (virtual) world. 😀
> > _______________________________________________
> > Opensim-users mailing list
> > Opensim-users at opensimulator.org
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>