[ 
https://issues.apache.org/jira/browse/HADOOP-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajesh Balamohan updated HADOOP-13047:
--------------------------------------
    Attachment: HADOOP-13047.WIP.2.patch

Agreed. Created "fs.s3a.readahead.buffer.size" which can be used for 
configuring the buffer size (initially thought of reusing io.file.buffer.size 
in S3AFileSystem, but it would be better to track s3a readahead separately).  

Created the patch which includes HADOOP-13028. Main changes are in 
seekInputStream. Patch should be a lot simplified once HADOOP-13028 is checked 
in.

> S3a Forward seek in stream length to be configurable
> ----------------------------------------------------
>
>                 Key: HADOOP-13047
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13047
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: fs/s3
>    Affects Versions: 2.8.0
>            Reporter: Steve Loughran
>         Attachments: HADOOP-13047.WIP.2.patch, HADOOP-13047.WIP.patch
>
>
> Even with lazy seek, tests can show that sometimes a short-distance forward 
> seek is triggering a close + reopen, because the threshold for the seek is 
> simply available bytes in the inner stream.
> A configurable threshold would allow data to be read and discarded before 
> that seek. This should be beneficial over long-haul networks as the time to 
> set up the TCP channel is high, and TCP-slow-start means that the ramp up of 
> bandwidth is slow. In such deployments, it will better to read forward than 
> re-open, though the exact "best" number will vary with client and endpoint.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to