[Opensim-dev] oddities with asset storage

[Buckaroo Mu]

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 at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>>>
>>>>     
>>>>         
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>>   
>>>       
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>>     
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>