8227080: (fs) Files.newInputStream(...).skip(n) is slow

[Florian Weimer]

* Brian Burkhalter:

> Hi Florian,
>
>  On Jul 3, 2019, at 7:11 AM, Florian Weimer <fweimer at redhat.com> wrote:
>
>  This patch overrides ChannelInputStream.skip(long) to use
>  SeekableByteChannel.position(long) if the ReadableByteChannel instance
>  is a SeekableByteChannel. The performance improvement on my dev
>  machine for skipping the first 2 GB of a local file is about 3.6 x
>  10^4.
>
>  Doesn't this need a fallback in case the seek operation fails?  I think
>  you can have FileChannels which are not seekable in practice, e.g. if
>  the file is actually a FIFO.
>
> Would that not violate the SeekableByteChannel specification?

I suppose it does, but what can FileChannel do if not all files in the
file system are seekable, in the sense that opening them does not give
you a seekable file descriptor?

> If the seek however actually did skip a few bytes before failing then
> it would be possible to skip an incorrect number of bytes in this
> case.

I think position(long) needs to be atomic regarding failure for this to
work.  That really should be the case on Linux (and I think for the core
file systems, this is actually thoroughly tested).

Thanks,
Florian