Closed tabokie closed 2 years ago
Merging #200 (ac1f1c2) into master (68ecbc9) will increase coverage by
0.00%
. The diff coverage is93.75%
.
@@ Coverage Diff @@
## master #200 +/- ##
=======================================
Coverage 96.95% 96.96%
=======================================
Files 28 28
Lines 7552 7568 +16
=======================================
+ Hits 7322 7338 +16
Misses 230 230
Impacted Files | Coverage Δ | |
---|---|---|
src/file_pipe_log/pipe_builder.rs | 95.09% <71.42%> (-1.83%) |
:arrow_down: |
src/engine.rs | 97.17% <100.00%> (-0.01%) |
:arrow_down: |
src/env/default.rs | 93.82% <100.00%> (+0.03%) |
:arrow_up: |
src/env/obfuscated.rs | 93.75% <100.00%> (ø) |
|
tests/failpoints/test_io_error.rs | 100.00% <100.00%> (ø) |
|
tests/failpoints/util.rs | 98.94% <100.00%> (ø) |
|
src/codec.rs | 98.67% <0.00%> (+0.33%) |
:arrow_up: |
src/file_pipe_log/format.rs | 93.68% <0.00%> (+3.15%) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 68ecbc9...ac1f1c2. Read the comment docs.
Signed-off-by: tabokie xy.tao@outlook.com
Previously
truncate
a written part will not reseek the file cursor. This could leave holes in log files.This case is now captured by failpoint tests. It wasn't covered before because all writes were done atomically, there's no chance to truncate a written part.
Also make the recovery process more robust. If the data is opened with the wrong file system, log files won't be mistakenly deleted.