8202116: (fc) FileChannel.map should ensure mapped region is backed by disk space

[Colin McCabe]

On Wed, Apr 25, 2018, at 00:42, Alan Bateman wrote:
> On 24/04/2018 19:00, Colin McCabe wrote:
>
>> :  It seems like the idea behind this change is to move the pre-
>> :  allocation to FileChannel#map, rather than having it in
>> :  RandomAccessFile#setLength.  This is definitely better than having
>> :  the preallocation in RandomAccessFile#setLength.> RandomAccessFile.setLength currently pre-allocates the space for the
> entire file. That was a mistake (in JDK 9 and 8uX) that only came to
> light in the last few days.> 
>  One option, which I don't like, but it's what we are discussing here
>  as it's straight-forward, is pre-allocating the disk space for the
>  mapped region (not the entire file). If you are memory mapping a
>  sparse file then the space will be allocated as you write to the
>  mapped byte buffer anyway (assuming you touch most of the region).> 
>  The other option that I'm playing with is treating BUS_ADDERR in the
>  same way as BUS_OBJERR so that unsafe access handler is invoked and
>  an exception thrown (as we have already when you truncate or remove
>  the file).> 
>
>> :  Finally, I would argue that the FileChannel#map operation itself
>> :  should not mutate the file.  In general, this operation is
>> :  supposed to create a view of the file, not change the file.> Right although the region that you map may not be completely contained
> in the file so it has to extend the file. This is the only case that
> I'm aware of where the file size changes, the map method never changes
> the contents of the file.> 
>
>> In general, it seems like what we really need is a way of translating
>> I/O errors on an mmaped file to exceptions.  Most Java developers are
>> not going to write signal handlers for SIGBUS.  But in order to have
>> robust software when using mmap, they may want to handle I/O errors.
>> It would be really good if Java would make this possible.
>> Preallocation doesn't fix this problem, and it adds other problems
>> which make mmap itself unappealing.
>>> The long standing spec is to throw an unspecified exception when
> part/all of the mapped region becomes inaccessible. So I think it's
> covered already, it's just that there are case that weren't handled
> correctly in the original implementation. JDK-6415680 is an example
> that was fixed in JDK 10.> 

Interesting.  I wasn't aware of that.  I've definitely gotten SIGBUS
errors in the past when using MappedByteBuffer, so I assumed that this
was the desired behavior.
As a developer, it would be helpful to have some information about
what part of the file had an error, and distinguish between ENOSPC and
EIO.  I know Linux, at least, provides (some of?) this information in
the SIGBUS signal that gets sent, although it's poorly documented.  If
Java was able to translate this information into the exception that
gets sent, that might be an interesting improvement to error reporting
and handling.
regards,
Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180425/a23e7937/attachment-0001.html>