The short term solution is to use the "last access" field for each of the assets and archive ones that haven't been used recently . So long as inventory is in one place (that is, you aren't splitting inventory across servers) you should be able to do some "simple" mysql magic to update the last access on anything referenced in the inventory (basically update last access time for any asset in the inventory table). that combination should pick up most everything given that textures on prims are reloaded from the asset server every 24 hours, scripts need to be recompiled on server restart... etc. <br /><br />--mic<br /><br /><br />On Feb 8, 2009 6:18pm, Charles Krinke <cfk@pacbell.net> wrote:<br />> Dear Mike:<br />> <br />> What you say seems reasonable and I applaud you.<br />> <br />> On the related subject of mutability, I have a tough time imagining that each edit of the terrain of a region is useful. I would suggest that only the last "terrainImage" is useful and cannot imagine any reference to any obsolete terrainImage by any object anywhere.<br />> <br />> There are a significant number of items in OpenSim mysql databases such as the various edits of a script where we appear to be storing a new UUID for each edit. In a similar manner, I would think that such obsolete edits are not useful.<br />> <br />> So, half of the problem is a strategy to slow down the bloat of our assetServers with perhaps additional references to additional assetServers and half is to perhaps re-consider all the orphaned items we are leaving in our<br />>  mysql database and find a way to stop doing that.<br />> <br />> Charles<br />> <br />> <br />> From: Mike Mazur mmazur@gmail.com><br />> To: opensim-dev@lists.berlios.de<br />> Sent: Sunday, February 8, 2009 6:11:46 PM<br />> Subject: Re: [Opensim-dev] AssetServer Observations and Suggestions<br />> <br />> <br />> Hi,<br />> <br />> On Sun, 8 Feb 2009 10:13:45 -0800 (PST)<br />> Charles Krinke cfk@pacbell.net> wrote:<br />> <br />> > We have been studying the assets table on OSGrid as it heads toward<br />> > the "disk full" stage and I have a couple of observations and am<br />> > heading towards a suggestion. Maybe this is already accounted for in<br />> > the "Cable Beach" project, at which point, this will only indicate<br />> > that I did not read all the exchanges carefully enough.<br />> > <br />> > It appears to me that we are storing on the MySQL data store at the<br />> > assetServer on a grid every edit of every script, terrainImage and<br />> > clothingItem amongst other things. So, my first observation is that<br />> > we appear to be storing all the older, obsolete items that can no<br />> > longer be accessed.<br />> <br />> This ever-expanding asset database is a consequence of how assets are<br />> handled by<br />>  SL, the SL viewer and, since OpenSim was first developed<br />> against the SL viewer, by OpenSim as well. The premise is that no asset<br />> is mutable, because any asset may be referenced by its UUID. The<br />> reference may exist in a script or on the back of a napkin. There are<br />> more details (the way I understand them) in a previous email[1] I sent<br />> to the list.<br />> <br />> Cable Beach will not solve this problem.<br />> <br />> > Now, to the beginnings of a suggestion. It seems to me that each<br />> > avatar will have a "home" region. And that perhaps that is the place<br />> > to store the items in an avatars inventory. Things like scripts,<br />> > notecards, textures and the like. <br />> <br />> I'm not sure this is the right way forward. It requires that the user's<br />> home region is up anytime they wish to use their avatar and access<br />> their inventory. The user's home region becomes a single point of<br />> failure.<br />> <br />> > At that point, the assetServer on a grid<br />>  could be used to store only<br />> > pointers (or URL's) to each avatars inventory on his or her home<br />> > region.<br />> <br />> This is a good start, except instead of pointing to the user's home<br />> region, it could point to the user's own asset server. The asset server<br />> could be provided by a grid (OSGrid), their own asset server (a Cable<br />> Beach instance, perhaps), or some other third party that may provide<br />> asset storage/access in the future (SL, Yahoo!, Google, AOL, etc).<br />> <br />> Thanks,<br />> Mike<br />> <br />> <br />> [1]<br />> https://lists.berlios.de/pipermail/opensim-dev/2008-December/004053.html<br />> _______________________________________________<br />> Opensim-dev mailing list<br />> Opensim-dev@lists.berlios.de<br />> https://lists.berlios.de/mailman/listinfo/opensim-dev<br />> <br />> <br />> <br />> <br />>