hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (Jira)" <j...@apache.org>
Subject [jira] [Work logged] (HADOOP-11867) FS API: Add a high-performance vectored Read to FSDataInputStream API
Date Fri, 25 Sep 2020 13:32:02 GMT

     [ https://issues.apache.org/jira/browse/HADOOP-11867?focusedWorklogId=490975&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-490975
]

ASF GitHub Bot logged work on HADOOP-11867:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 25/Sep/20 13:31
            Start Date: 25/Sep/20 13:31
    Worklog Time Spent: 10m 
      Work Description: hadoop-yetus removed a comment on pull request #1830:
URL: https://github.com/apache/hadoop/pull/1830#issuecomment-696332135






----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 490975)
    Time Spent: 6h 20m  (was: 6h 10m)

> FS API: Add a high-performance vectored Read to FSDataInputStream API
> ---------------------------------------------------------------------
>
>                 Key: HADOOP-11867
>                 URL: https://issues.apache.org/jira/browse/HADOOP-11867
>             Project: Hadoop Common
>          Issue Type: New Feature
>          Components: fs, fs/azure, fs/s3, hdfs-client
>    Affects Versions: 3.0.0
>            Reporter: Gopal Vijayaraghavan
>            Assignee: Owen O'Malley
>            Priority: Major
>              Labels: performance, pull-request-available
>          Time Spent: 6h 20m
>  Remaining Estimate: 0h
>
> The most significant way to read from a filesystem in an efficient way is to let the
FileSystem implementation handle the seek behaviour underneath the API to be the most efficient
as possible.
> A better approach to the seek problem is to provide a sequence of read locations as part
of a single call, while letting the system schedule/plan the reads ahead of time.
> This is exceedingly useful for seek-heavy readers on HDFS, since this allows for potentially
optimizing away the seek-gaps within the FSDataInputStream implementation.
> For seek+read systems with even more latency than locally-attached disks, something like
a {{readFully(long[] offsets, ByteBuffer[] chunks)}} would take of the seeks internally while
reading chunk.remaining() bytes into each chunk (which may be {{slice()}}ed off a bigger buffer).
> The base implementation can stub in this as a sequence of seeks + read() into ByteBuffers,
without forcing each FS implementation to override this in any way.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org


Mime
View raw message