ctrlaltluc commented on PR #14543: URL: https://github.com/apache/kafka/pull/14543#issuecomment-1761528683
> Given that, I'm not sure if we should fsync inside the lock at the cost of performance impact. @ocadaruma thanks for your reply! You are correct, it is against failure at OS level, not Kafka process level. I agree it is rare and if replication was successful, the data loss is not complete. If this is a conscious design decision, sounds good to me. I was not familiar with Jack Vanlightly's post, although I coincidentally read [this other post](https://jack-vanlightly.com/blog/2023/5/15/kafka-vs-redpanda-performance-do-the-claims-add-up) just a few days back. Should subscribe to the RSS. Thanks! Concluding, I have no issues dropping the PR and closing the ticket as being solved by swallowing `NoSuchFileException`. The most important part of the fix for us is to avoid having the whole log dir become offline, which is covered. If there are no other replies or concerns until Monday, I will close this PR and link the JIRA ticket as being solved by https://issues.apache.org/jira/browse/KAFKA-15391. -- 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
