You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Øystein Grøvlen <Oy...@Sun.COM> on 2005/05/25 14:16:22 UTC
Re: [jira] Commented: (DERBY-298) rollforward will not work correctly
if the system happens to crash immediately after rollforward backup.
>>>>> "ST" == Suresh Thalamati <su...@gmail.com> writes:
ST> derby has two types of log files , one that works in RWS mode with a
ST> preallocated log file ,
What is RWS mode?
ST> and one which uses file sync with out preallocation. In case of
ST> preallocation , zeros are written to the log file to the length
ST> specified by the logSwitchInterval (Default is 1 MB) , it is also
ST> configurable by the user.
What determines which mode is used?
ST> This problem can also be fixed by writing dummy log record.
ST> Filelogger.redo() code has to be fixed to understand this, currently
ST> it looks at the logEnd only when a good log records is read.
I was thinking that the "dummy" log record should be a "good" log
record so that the current implementation of redo() need not change.
ST> Another possible solution I was thinking to identify whether a log
ST> switch is good or not is by writing a INT (4 bytes of zeros ) after
ST> log file initialization. As 512 bytes writes suppose to be atomic.
ST> if (log file length > = LOG_FILE_HEADER_SIZE(24) +4) then the log
ST> switch before the crash can be fixed as good one and fix the scan code
ST> to use the empty log file instead of writing to the previous log file.
I am not sure I understood this. Do you suggest writing the INT just
after the header? Would this work for preallocated log files? Would
not the length always be 1 MB (default) in that case?
--
Øystein
Re: [jira] Commented: (DERBY-298) rollforward will not work correctly
if the system happens to crash immediately after rollforward backup.
Posted by Suresh Thalamati <su...@gmail.com>.
Øystein Grøvlen wrote:
>>>>>>"ST" == Suresh Thalamati <su...@gmail.com> writes:
>>>>>>
>>>>>>
>
> ST> derby has two types of log files , one that works in RWS mode with a
> ST> preallocated log file ,
>
>What is RWS mode?
>
>
RWS mode is writing transction log using the write sync mechanism
supported by java.io.RandomaccessFile from jdk1.4.2 onwards, when a
file is opened with "rws" , all writes to the file are synced to the
disk on the write call itself.
> ST> and one which uses file sync with out preallocation. In case of
> ST> preallocation , zeros are written to the log file to the length
> ST> specified by the logSwitchInterval (Default is 1 MB) , it is also
> ST> configurable by the user.
>
>What determines which mode is used?
>
>
Write sync is the default mode when derby is run on jvm after
jdk1.4.2. users can also specify the engine to use
file sync mode , for example to avoid Derby-1 problem on Mac-OS.
> ST> This problem can also be fixed by writing dummy log record.
> ST> Filelogger.redo() code has to be fixed to understand this, currently
> ST> it looks at the logEnd only when a good log records is read.
>
>I was thinking that the "dummy" log record should be a "good" log
>record so that the current implementation of redo() need not change.
> ST> Another possible solution I was thinking to identify whether a log
> ST> switch is good or not is by writing a INT (4 bytes of zeros ) after
> ST> log file initialization. As 512 bytes writes suppose to be atomic.
> ST> if (log file length > = LOG_FILE_HEADER_SIZE(24) +4) then the log
> ST> switch before the crash can be fixed as good one and fix the scan code
> ST> to use the empty log file instead of writing to the previous log file.
>
>I am not sure I understood this. Do you suggest writing the INT just
>after the header?
>
Yes. If the header is written to the disk completely, then, it is
safe to say log switch is completed successfully.
Basically:
1) Write the header and do a file sync as it done currently.
2) Wrie a INT(4 bytes of zeros) and do a file sync.
On scan if the log file size is >= LOG_FILE_HEADER_SIZE(24) +4 ,
then the log file switch was successful before the crash.
It can be used as the next log file.
> Would this work for preallocated log files?
>
I think so, preallocation is done only for performance reasons. For some reason if the preallocation did not complete, recovery should work fine. just that log writes will be slower until the next switch.
>Would
>not the length always be 1 MB (default) in that case?
>
>
>
Not sure I understand this question completely. Length will not be 1MB
(default) If the crash occurs after log file initialization , but before
preallocation. It will be just LOG_FILE_HEADER_SIZE(24) +4 .
Thanks
-suresh