Hi, i proposed a reaping strategy that is both type and time based. There was no direct response to it, but current development on new de-duping cable beach plugins may go a long way to curb asset proliferation and the reaper can be developed on that basis. Refcounting may be feasible as a positive indication, e.g. to indicate something is _definitely_ safe to delete, but a reaper will still be required.
Melanie Buckaroo Mu wrote: > Melanie wrote: >> This is something i have though about. However, it would not work in >> OSGrid. Regions may go away, and they may go away permanently. >> Anything in a prim inventory at that time is refcounted and would >> not be released. Ever. >> > In what what in particular would this be worse than the current > situation? Yes, some assets would end up staying around forever. > However, unlike the current scheme, some... would not. >> So, you'd need a ref list, to purge invalid refs. That is where the >> inpracticability begins. A redf list for each and every asset, >> listing either avatar UUID or region UUID? >> >> > Eep, no - wasn't considering suggesting this. >> If assets are 51 mio, how long will the reflist table be? >> >> Melanie >> >> Buckaroo Mu wrote: >> >>> Here's my L$0.02, for what it's worth - why not maintain a 'reference >>> count' in the asset entry? >>> >>> Resident A creates a prim, takes it into inventory. Asset is created, >>> inventory item pointing to asset is created, asset->useagecount++. User >>> gives away 15 copies of item, asset->usagecount+=15. Resident A deletes >>> original item, inventory item goes away, asset->usagecount--. >>> >>> Resident B rezzes item on sim. If item is no-copy, asset->usagecount--. >>> If it's copy, and Resident B (or Resident C) takes it back into >>> inventory, asset->usagecount++ (they would have two copies of it). >>> Resident B deletes both copies from inventory, asset->usagecount -=2. >>> >>> If asset->usagecount == 0, asset gets deleted. >>> >>> Tell me why this wouldn't work. I'm sure there's a simple reason, but I >>> can't think of it. All of this is assuming that the asset is no-mod - >>> any change to the asset creates a new UUID, correct? But if the asset is >>> rezzed, then taken back into inventory, it should have the same UUID, >>> thus adding one to the usage count. >>> >>> -Buckaroo >>> >>> Melanie wrote: >>> >>>> All you described is design behavior. >>>> >>>> >>>> Prim items in world are not assets. They are stored exclusively in >>>> the prims tables of the region. >>>> >>>> Once taken, they become an asset. The name is totally meaningless, >>>> it reflects whatever was the name at creation. Nothing else. It >>>> never changes from there on. >>>> >>>> On deleting the inventory item, assets remain. There is no easy or >>>> practicable way to conclusively say that an asset is trash, because >>>> we don't know. >>>> >>>> In your test case, your (human) mind could know this for a fact, >>>> however, the silicon mind of the asset server can't. >>>> >>>> This is because you may have given the object to another user, or >>>> put a copy into a prim. >>>> >>>> These copies would refer to the same asset, that is what "implictily >>>> shared" means. >>>> >>>> So, any asset may, at any time, have any number of links to it, even >>>> zero. >>>> >>>> Like a website, you don't know who linked to it. If you remove it, >>>> you leave dead links. Assets are the same. Except, you get "Asset >>>> missing from database". >>>> >>>> So, assetas are NOT 1-to-1 with inventory items, and they _never_ >>>> get deleted. >>>> >>>> They have to be reaped, and there is a big discussion over how to >>>> best do that, running right now. >>>> >>>> Melanie >>>> >>>> >>>> Dirk Krause wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> I did a little test with a fresh OpenSim installation (yes, thanks for >>>>> the installer!), >>>>> to get a grip on what I learned from Melanie yesterday. >>>>> >>>>> I wrote a little python script to help me monitor these tables: >>>>> inventoryStore/inventoryItems >>>>> assetStorage/assets >>>>> http://pastebin.com/mc9e6574 , be warned: ugly code. >>>>> >>>>> I started OpenSim and logged in a 'Test User' with the SL viewer. >>>>> >>>>> (Just to mention it - first time log in in as test users creates >>>>> 4 'blank' entries in assets.) >>>>> >>>>> The inventoryItems table was initially empty. >>>>> >>>>> Now I rezzed a cube and renamed it to 'p1'. >>>>> inventoryStore/inventoryItems was still empty. >>>>> To my surprise no new entry shows up in assetStorage/assets. >>>>> >>>>> Picking up the cube ('take') created an entry named 'p1' in the >>>>> inventory and in the asset table. >>>>> >>>>> Now I renamed the cube in Test Users inventory to 'p2'. >>>>> The name in inventoryStore/inventoryItems changes to 'p2'. >>>>> The entry in assetStorage/assets stays 'p1'. As mentioned on the list >>>>> before, >>>>> the asset name is useless, since the user only sees the name in the >>>>> inventory. >>>>> >>>>> Now I deleted 'p2' in my inventory - 'p2's parentfolderID changes to >>>>> 'Trash'. >>>>> Now I emptied the trash - the inventory table is empty again, which is >>>>> fine, >>>>> but here's the big one: >>>>> the assetStorage/assets still holds the reference to 'p1'. >>>>> >>>>> Just to make sure I shut down the simulator and opened it again, and it >>>>> was still there. >>>>> >>>>> Now, doesn't that mean, that the database increases over time with no >>>>> hope to find >>>>> these assets that actually should be gone? or is there some magic >>>>> purging that happens, >>>>> and that I missed? >>>>> >>>>> This would mean that any grid runs into a severe problem over time. >>>>> >>>>> Best, >>>>> Dirk/Bart >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev@lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev@lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
