8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space

[Ismael Juma]

Seems like JDK-8202261 has been merged. Would a backport to Java 10 be
considered? We would like to recommend Java 10 for Kafka users due to much
faster TLS and CRC32C, but the increased disk usage (without JDK-8202261)
could take users by surprise.

Ismael

On Thu, Apr 26, 2018 at 7:21 AM, Ismael Juma <mlists at juma.me.uk> wrote:

> Thanks Alan, the latest proposal sounds good to me.
>
> On Wed, Apr 25, 2018 at 7:46 AM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> Take 2 ...
>>
>> As we've been discussing in the other threads, the changes in JDK-8168628
>> in JDK 9 and 8uX were a mistake that we need to fix.
>>
>> I've re-examined the error logs from the original bug report, also fresh
>> core files using Brian's test, and I'm now confident the underlying issue
>> is that the bulk transfer operations (based on unsafe copyMemory) aren't
>> guarded, hence the SIGBUS handler doesn't translate the fault into an
>> exception. The single element put/get use unsafe operations with memory
>> guards so they will throw an exception when the underlying file is
>> truncated, removed, or there isn't disk space available (usually BUS_OBJERR
>> or BUS_ADRERR). David Holmes confirmed with a link to JDK-8191278 where the
>> issue with Unsafe.copyMemory is tracked.
>>
>> In the mean-time, we can partly workaround the original issue with the
>> changes that we discussed via JDK-8202116. I'm not comfortable with that
>> change, even on ext4 where fallocate just allocates the meta data to
>> support the additional space. While it addresses the original issue, it
>> doesn't help with bulk transfers faulting for other reasons.
>>
>> So I've decided to close JDK-8202116 and instead use a subset of that
>> patch to revert JDK-8168628. In summary, this reverts
>> RandomAccessFile.setLength and FileChannel.map so that they don't
>> preallocate space. The rest is just cleanup.
>>
>> http://cr.openjdk.java.net/~alanb/8202261/webrev/index.html
>>
>> -Alan
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180426/248c6f46/attachment.html>