[Opensim-dev] oddities with asset storage

[Melanie]

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.

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?

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
> 
>