hibari / gdss-brick

http://hibari.github.com/hibari-doc/
Other
11 stars 2 forks source link

gmt_hlog families should track each hlog's location (short-term v.s. long-term) #16

Closed tatsuya6502 closed 8 years ago

tatsuya6502 commented 11 years ago

During code review, I found that gmt_hlog_common and gmt_hlog_local don't track each hlog's location (if it's is short-term or long-term storage) so gmt_hlog:open_log_file/2 has to call file:open/2 twice if the hlog has been moved to the long-term storage.

https://github.com/hibari/gdss-brick/blob/master/src/gmt_hlog.erl#L1104

open_log_file(Dir, N, Options) ->
    Path = log_file_path(Dir, N),
    case file:open(Path, [binary, raw|Options]) of
        {error, enoent} when N > 0 ->
            %% Retry: perhaps this file was moved to long-term storage?
            ?DBG_TLOGx({open_log_file, Dir, N, Options, Path, retry}),
            open_log_file(Dir, -N, Options);
        Res ->
            ?DBG_TLOGx({open_log_file, Dir, N, Options, Path, Res}),
            Res
    end.

This is not an optimal solution. Though moving an hlog is done by a separate process and this kind of code block can't be removed completely, they should remember the locations so they can do better in next time.

tatsuya6502 commented 8 years ago

This is no longer applicable. I have removed gmt_log familes from v0.3.0 stream as the major part of redesigning disk storage (https://github.com/hibari/gdss-brick/issues/17).

Closing without fixing it.