No subject

database growth, and a reaping strategy would enforce that, so that =
would be ok.

If there'd be another strategy that would make reaping unnecessary, I'd =
welcome that. To me one solution involving different data =
responsibilities and quotas smells like such a solution.

-- Dirk/Bart

-----Urspr=FCngliche Nachricht-----
Von: opensim-dev-bounces at lists.berlios.de =
[mailto:opensim-dev-bounces at lists.berlios.de] Im Auftrag von Melanie
Gesendet: Donnerstag, 19. Februar 2009 03:27
An: opensim-dev at lists.berlios.de
Betreff: Re: [Opensim-dev] oddities with asset storage

Hi,

i proposed a reaping strategy that is both type and time based.=20
There was no direct response to it, but current development on new=20
de-duping cable beach plugins may go a long way to curb asset=20
proliferation and the reaper can be developed on that basis.=20
Refcounting may be feasible as a positive indication, e.g. to=20
indicate something is _definitely_ safe to delete, but a reaper will=20
still be required.

Melanie

Buckaroo Mu wrote:
> Melanie wrote:
>> This is something i have though about. However, it would not work in=20
>> OSGrid. Regions may go away, and they may go away permanently.=20
>> Anything in a prim inventory at that time is refcounted and would=20
>> not be released. Ever.
>>  =20
> In what what in particular would this be worse than the current=20
> situation? Yes, some assets would end up staying around forever.=20
> However, unlike the current scheme, some... would not.
>> So, you'd need a ref list, to purge invalid refs. That is where the=20
>> inpracticability begins. A redf list for each and every asset,=20
>> listing either avatar UUID or region UUID?
>>
>>  =20
> Eep, no - wasn't considering suggesting this.
>> If assets are 51 mio, how long will the reflist table be?
>>
>> Melanie
>>
>> Buckaroo Mu wrote:
>>  =20
>>> Here's my L$0.02, for what it's worth - why not maintain a =
'reference=20
>>> count' in the asset entry?
>>>
>>> Resident A creates a prim, takes it into inventory. Asset is =
created,=20
>>> inventory item pointing to asset is created, asset->useagecount++. =
User=20
>>> gives away 15 copies of item, asset->usagecount+=3D15. Resident A =
deletes=20
>>> original item, inventory item goes away, asset->usagecount--.
>>>
>>> Resident B rezzes item on sim. If item is no-copy, =
asset->usagecount--.=20
>>> If it's copy, and Resident B (or Resident C) takes it back into=20
>>> inventory, asset->usagecount++ (they would have two copies of it).=20
>>> Resident B deletes both copies from inventory, asset->usagecount =
-=3D2.
>>>
>>> If asset->usagecount =3D=3D 0, asset gets deleted.
>>>
>>> Tell me why this wouldn't work. I'm sure there's a simple reason, =
but I=20
>>> can't think of it. All of this is assuming that the asset is no-mod =
-=20
>>> any change to the asset creates a new UUID, correct? But if the =
asset is=20
>>> rezzed, then taken back into inventory, it should have the same =
UUID,=20
>>> thus adding one to the usage count.
>>>
>>> -Buckaroo
>>>
>>> Melanie wrote:
>>>    =20
>>>> 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:
>>>>  =20
>>>>      =20
>>>>> 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
>>>>>
>>>>>
>>>>>    =20
>>>>>        =20
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>>>
>>>>  =20
>>>>      =20
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>>    =20
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>>  =20
>=20
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>=20
>=20
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev