[
https://issues.apache.org/jira/browse/KAFKA-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15320467#comment-15320467
]
Ismael Juma commented on KAFKA-3802:
------------------------------------
Thanks for the investigation [~moritz]. Good job finding the source of the
issue. The documentation of `truncate` says:
{code}
* <p> If the given size is less than the file's current size then the file
* is truncated, discarding any bytes beyond the new end of the file. If
* the given size is greater than or equal to the file's current size then
* the file is not modified. In either case, if this channel's file
* position is greater than the given size then it is set to that size.
{code}
So, it looks like a bug in the JDK, potentially fixed in JDK 8.
As an aside, it's a bit odd that `truncateTo` sets the position unconditionally
to `targetSize`, but that's a topic for another JIRA, I guess.
> log mtimes reset on broker restart
> ----------------------------------
>
> Key: KAFKA-3802
> URL: https://issues.apache.org/jira/browse/KAFKA-3802
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.9.0.1
> Reporter: Andrew Otto
>
> Folks over in
> http://mail-archives.apache.org/mod_mbox/kafka-users/201605.mbox/%3CCAO8=cz0ragjad1acx4geqcwj+rkd1gmdavkjwytwthkszfg...@mail.gmail.com%3E
> are commenting about this issue.
> In 0.9, any data log file that was on
> disk before the broker has it's mtime modified to the time of the broker
> restart.
> This causes problems with log retention, as all the files then look like
> they contain recent data to kafka. We use the default log retention of 7
> days, but if all the files are touched at the same time, this can cause us
> to retain up to 2 weeks of log data, which can fill up our disks.
> This happens *most* of the time, but seemingly not all. We have seen broker
> restarts where mtimes were not changed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
