Subject | RE: [IB-Architect] Next ODS change (was: System table change) |
---|---|
Author | Ann Harrison |
Post date | 2000-11-09T15:10:32Z |
Claudio,
"Next ODS Change." My goal is to collect all the ideas we have for
ODS changes so they can be made at once. Certainly, saving 2 bytes
per page would not be a reason to change the ODS in and of itself.
protection minimal. Perhaps we should increase the space so something
like the torn algorithm could be used?
must be set long after the garbage has gone out. But sure, there might
be a case where turning on checksumming would be a reasonable diagnostic.
Regards,
Ann
>Abandoned for performance, but:Yes absolutely. But if you check the subject of this message it's
>- Deleting checksum space would mean an immediate ODS change, right?
"Next ODS Change." My goal is to collect all the ideas we have for
ODS changes so they can be made at once. Certainly, saving 2 bytes
per page would not be a reason to change the ODS in and of itself.
>- Also, if someone wants to trade extra reliability for less performance,Right. But in this case, the performance hit is enormous and the
>checksum can be enabled. If you remove those bytes, that tweak can't be done
>in the future. Make sure there's enough reasons to justify the gained space.
protection minimal. Perhaps we should increase the space so something
like the torn algorithm could be used?
>- What if someone wants the feature to track a ghost error that might comeGarbage collection wouldn't show up, since the checksum (or whatever)
>from faulty hardware or SMP operation or garbage collection bug, etc?
must be set long after the garbage has gone out. But sure, there might
be a case where turning on checksumming would be a reasonable diagnostic.
Regards,
Ann