ocadaruma commented on PR #14242: URL: https://github.com/apache/kafka/pull/14242#issuecomment-1704786562
@showuon Thank you for your review. 0) Got it. I revised the PR description to include analysis. 2) The actual change is made against `SnapshotFile.java#renameTo`, which is called from removeAndMarkSnapshotForDeletion. 3) > We can always recover from logs when unclean shutdown. Yes. However, precisely, removing fsync on `LeaderEpochFileCache`'s truncation doesn't cause extra recovery even on unclean shutdown IMO. The reason: - Since we still fsync on `LeaderEpochFileCache#assign`, we can still ensure all necessary leader epochs are in leader-epoch cache file - Even when truncation is not flushed (so "should-be-truncated" epochs may be left on the epoch file on unclean shutdown), log-loading procedure should truncate the epoch file as necessary (based on the log start/end offset). It's a fairly right-weight operation comparing to the recovering from the log. - Hmm, I intentionally didn't create a overloaded method because I was afraid a bit that default (fsync: true) method is used casually in the future code change even for the place which fsync isn't necessary. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
