Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Why did FLUSH solve this problem?
Message
De
10/05/2001 15:35:51
 
 
À
10/05/2001 14:11:54
Gerry Schmitz
GHS Automation Inc.
Calgary, Alberta, Canada
Information générale
Forum:
Visual FoxPro
Catégorie:
FoxPro 2.x
Divers
Thread ID:
00505050
Message ID:
00505950
Vues:
28
Gerry,

But you are really describing a very specific case - crash time.
A "write behind" mechanism (posting complete when writing not yet done) is probably quite common in controllers and should theoretically be no problem when the controller can intercept/inspect the requested I/O and supply the correct data.
Obviously, when the hardware fails there could be a problem. I suppose that to be perfectly safe there should be a way (probably is) to turn THAT option off but to leave caching operational.

That has got to be a dicey situation for any hardware even at the best of times.

The case that started this thread was regarding regular healthy processing and Craig was saying that bad caching (hardware) was the problem. Al D. countered with a doubt in that regard and I went along with Al D.

My bet in the case for this thread is that VFP - more specifically the combination of settings in effect - causes the situation described. Sure wish it was published which setting combinations are good and bad.

Cheers,

JimN

>>Write caching is a technology that's been around for a long time. It's well understood and has been reliably implemented in thousands of different configurations. Turning it off can result in a large performance hit and should never be undertaken lightly.<
>
>It's not "write caching" that is the problem per se; it's the "I/O complete" notification.
>
>Apparently, there were/are some controllers that would notify the O/S that "I/O is complete", when in fact it wasn't; they would post the notification and then do the writing ("write-behind", I think it's called). A problem could arise now if the controller (or something) crashed and there was no battery backup; the "system" assumes the data was written, when in fact it wasn't and there is no way to recover. Or ... one could "reset" the controller, which would dump the cach, possibly AFTER a notification was sent but before the write.
>
>In any event, turning of write-caching (with SQL Server) "might" not make a "big" difference (5% at 250 I/O per sec).
>
>One controller that supposedly can handle the above issues is the "Compaq SMART-2" (whatever that is).
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform