No subject

t inventory to me - we did until recently have some lost assets after SI se=
ssions due to asset server crashing - previously the code would attempt to =
store assets with descriptions bigger than database field length. This seem=
ed to happen mostly with SI uploaded items but also was 100% reproducible i=
f you had a sim with a long name and a parcel with a long name and attempte=
d to create a landmark - there are checks now to stop this from happening t=
hat Justin kindly committed (and he was good enough to add similar checks f=
or MySQL) and we've not had a crash since applying that patch over a we=
ek and a half ago. In terms of actual inventory, no-one has reported loss o=
f specific items. Sometimes slow to load, but not loss.<br>

<br>
Is this something that has happened since 0.6.6 tag?<br>
<br>
Chris<br>
<div class=3D"im"><br>
-----Original Message-----<br>
From: <a href=3D"mailto:opensim-dev-bounces at lists.berlios.de">opensim-dev-b=
ounces at lists.berlios.de</a> [mailto:<a href=3D"mailto:opensim-dev-bounces at l=
ists.berlios.de">opensim-dev-bounces at lists.berlios.de</a>] On Behalf Of Mel=
anie<br>

</div><div><div></div><div class=3D"h5">Sent: 27 July 2009 14:32<br>
To: <a href=3D"mailto:opensim-dev at lists.berlios.de">opensim-dev at lists.berli=
os.de</a><br>
Subject: Re: [Opensim-dev] Inventory loss<br>
<br>
Those MySQL issues listed below and others like it are corner cases<br>
that OpenSim would never trigger. OpenSim is a very simplistic<br>
database user, it doesn't even really use any relational features of<br=
>
the database.<br>
So, I don't think that MySQL errors are something we need to concern<br=
>
ourselves with at this point. Especially, your suggestion would not<br>
help in those cases, as they are all about complete loss of rows.<br>
That is unaffected by a "deleted" type flag.<br>
<br>
That is neither here nor there anyway, since such a "deleted" fla=
g<br>
would have to live under OpenSim.Data.XXXX.<br>
<br>
It has no business being in core at all.<br>
<br>
Melanie<br>
<br>
<br>
Colin B. Withers wrote:<br>
> Reason I wondered is simply the number of websites dedicated to recove=
ring from MYSQL database corruption, and offering tools for the same. Googl=
e returns over 250,000 sites for 'mysql database corruption'.<br>

><br>
> MYSQL has had numerous bug fixes to fix database corruption, introduce=
d by differing versions of MYSQL, eg<br>
><br>
> Fixed in 4.0.18<br>
> INSERT DELAYED ... SELECT ... could cause table corruption because tab=
les were not locked properly. This is now fixed by ignoring DELAYED in this=
 context. (Bug #1983)<br>
><br>
> Fixed in 4.0.16<br>
> Fixed bug in overrun check for BLOB values with compressed tables. Thi=
s was a bug introduced in 4.0.14. It caused MySQL to regard some correct ta=
bles containing BLOB values as corrupted. (Bug #770, Bug #1304, and maybe B=
ug #1295)<br>

><br>
> Fixed in 4.0.15<br>
> Fixed rare bug in MYISAM introduced in 4.0.3 where the index file head=
er was not updated directly after an UPDATE of split dynamic rows. The symp=
tom was that the table had a corrupted delete-link if mysqld was shut down =
or the table was checked directly after the update.<br>

><br>
> Fixed in 4.0.14<br>
> Comparison/sorting for latin1_de character set was rewritten. The old =
algorithm could not handle cases like "s=E4" < "=DFa&quot=
;. See section 5.6.1.1 German character set. In rare cases, it resulted in =
table corruption.<br>

><br>
> and so on..<br>
><br>
> My own experience with Opensim is that in the last 12 months there has=
 been three occasions where residents complained of stuff 'missing'=
 (not a single resident, but several at once) and a roll-back to the last d=
atabase backup cured the problems.<br>

><br>
> Rock<br>
><br>
> -----Original Message-----<br>
> From: <a href=3D"mailto:opensim-dev-bounces at lists.berlios.de">opensim-=
dev-bounces at lists.berlios.de</a> [mailto:<a href=3D"mailto:opensim-dev-boun=
ces at lists.berlios.de">opensim-dev-bounces at lists.berlios.de</a>] On Behalf O=
f Melanie<br>

> Sent: Monday, July 27, 2009 2:07 PM<br>
> To: <a href=3D"mailto:opensim-dev at lists.berlios.de">opensim-dev at lists.=
berlios.de</a><br>
> Subject: Re: [Opensim-dev] Inventory loss<br>
><br>
> IMHO, inventory loss due to MySQL errors and/or corruption are below<b=
r>
> the radar.<br>
> Any losses would occur in OpenSim code, I believe.<br>
><br>
> Melanie<br>
><br>
> Colin B. Withers wrote:<br>
>> I wonder what proportion of inventory items that go astray are the=
 result of the success/failure of an operation, or are due to database corr=
uption issues.<br>
>><br>
>> Rock<br>
>><br>
>> -----Original Message-----<br>
>> From: <a href=3D"mailto:opensim-dev-bounces at lists.berlios.de">open=
sim-dev-bounces at lists.berlios.de</a> [mailto:<a href=3D"mailto:opensim-dev-=
bounces at lists.berlios.de">opensim-dev-bounces at lists.berlios.de</a>] On Beha=
lf Of Melanie<br>

>> Sent: Monday, July 27, 2009 12:30 PM<br>
>> To: <a href=3D"mailto:opensim-dev at lists.berlios.de">opensim-dev at li=
sts.berlios.de</a><br>
>> Subject: Re: [Opensim-dev] Inventory loss<br>
>><br>
>> There is a question here of why inventory loss occurs at all. At<b=
r>
>> what stage do we actually lose (as opposed to failing to bump the<=
br>
>> folder serial) inventory items at all, and why?<br>
>><br>
>> While a "deleted" flag and an undelete function do make =
an admin's<br>
>> life easier, I believe the real focus should be on the inventory<b=
r>
>> code. It will be redesigned anyway and once that happens, I think =
a<br>
>> strong focus needs to be placed on data integrity preservation.<br=
>
>><br>
>> That would then mae the undelete functionality largely unnecessary=
.<br>
>> Current inventory code often doesn't check for success of an<b=
r>
>> operation at all. That needs to be revisited.<br>
>><br>
>> Melanie<br>
>><br>
>> Thomas Grimshaw wrote:<br>
>>> Hey folks.<br>
>>><br>
>>> Been thinking a lot about inventory loss in OpenSim, something=
 that I<br>
>>> think we should really do as much as possible to avoid. We&#39=
;ve been<br>
>>> experiencing numerous cases of lost inventory in K-Grid recent=
ly.<br>
>>><br>
>>> What i'd like to implement, is..<br>
>>><br>
>>> When an item is removed from inventory (deleted, or rezzed if =
it's<br>
>>> no-copy), it is not actually deleted by instead an "avail=
able" flag is<br>
>>> set in the inventory database.<br>
>>> All inventory queries will check for the flag and thus it will=
 appear as<br>
>>> deleted to the user, but it can be restored easily by an admin=
 if<br>
>>> needed. =A0A timestamp should also be set which indicates when=
 the item<br>
>>> was made unavailable, so that routine cleanup can be performed=
 on items<br>
>>> which were made unavailable a long time ago.<br>
>>><br>
>>> I wanted to get people's opinons of this before I implemen=
ted it in<br>
>>> code. Can anyone think of any drawbacks or possible issues? An=
y further<br>
>>> room for improvement?<br>
>>><br>
>>> Cheers<br>
>>><br>
>>> Thomas Grimshaw<br>
>>> (RemedyTomm)<br>
>>> _______________________________________________<br>
>>> Opensim-dev mailing list<br>
>>> <a href=3D"mailto:Opensim-dev at lists.berlios.de">Opensim-dev at li=
sts.berlios.de</a><br>
>>> <a href=3D"https://lists.berlios.de/mailman/listinfo/opensim-d=
ev" target=3D"_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev=
</a><br>
>>><br>
>>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href=3D"mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.=
berlios.de</a><br>
>> <a href=3D"https://lists.berlios.de/mailman/listinfo/opensim-dev" =
target=3D"_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>=
<br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href=3D"mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.=
berlios.de</a><br>
>> <a href=3D"https://lists.berlios.de/mailman/listinfo/opensim-dev" =
target=3D"_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>=
<br>
>><br>
>><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href=3D"mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.berl=
ios.de</a><br>
> <a href=3D"https://lists.berlios.de/mailman/listinfo/opensim-dev" targ=
et=3D"_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href=3D"mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.berl=
ios.de</a><br>
> <a href=3D"https://lists.berlios.de/mailman/listinfo/opensim-dev" targ=
et=3D"_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>
><br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href=3D"mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.berlios.d=
e</a><br>
<a href=3D"https://lists.berlios.de/mailman/listinfo/opensim-dev" target=3D=
"_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br>
</div></div>No virus found in this incoming message.<br>
Checked by AVG - <a href=3D"http://www.avg.com" target=3D"_blank">www.avg.c=
om</a><br>
Version: 8.5.392 / Virus Database: 270.13.29/2261 - Release Date: 07/27/09 =
05:58:00<br>
<div><div></div><div class=3D"h5">_________________________________________=
______<br>
Opensim-dev mailing list<br>
<a href=3D"mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.berlios.d=
e</a><br>
<a href=3D"https://lists.berlios.de/mailman/listinfo/opensim-dev" target=3D=
"_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Michael Emo=
ry Cerquoni - Nebadon Izumi @ <a href=3D"http://osgrid.org">http://osgrid.o=
rg</a><br>

--000e0cd47e38287f0e046fbd7b42--