[
https://issues.apache.org/jira/browse/HADOOP-11867?focusedWorklogId=713622&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-713622
]
ASF GitHub Bot logged work on HADOOP-11867:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 24/Jan/22 10:03
Start Date: 24/Jan/22 10:03
Worklog Time Spent: 10m
Work Description: mukund-thakur commented on a change in pull request
#3904:
URL: https://github.com/apache/hadoop/pull/3904#discussion_r790581863
##########
File path:
hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/fs/contract/AbstractContractVectoredReadTest.java
##########
@@ -120,6 +119,71 @@ public void testVectoredReadAndReadFully() throws
Exception {
}
}
+ /**
+ * As the minimum seek value is 4*1024,none of the below ranges
+ * will get merged.
+ */
+ @Test
+ public void testDisjointRanges() throws Exception {
+ FileSystem fs = getFileSystem();
+ List<FileRange> fileRanges = new ArrayList<>();
+ fileRanges.add(new FileRangeImpl(0, 100));
+ fileRanges.add(new FileRangeImpl(4 *1024 + 101, 100));
+ fileRanges.add(new FileRangeImpl(16*1024 + 101, 100));
+ try (FSDataInputStream in = fs.open(path(VECTORED_READ_FILE_NAME))) {
+ in.readVectored(fileRanges, allocate);
+ validateVectoredReadResult(fileRanges);
+ }
+ }
+
+ /**
+ * As the minimum seek value is 4*1024, all the below ranges
+ * will get merged into one.
+ */
+ @Test
+ public void testAllRangesMergedIntoOne() throws Exception {
+ FileSystem fs = getFileSystem();
+ List<FileRange> fileRanges = new ArrayList<>();
+ fileRanges.add(new FileRangeImpl(0, 100));
+ fileRanges.add(new FileRangeImpl(4 *1024 - 101, 100));
+ fileRanges.add(new FileRangeImpl(8*1024 - 101, 100));
+ try (FSDataInputStream in = fs.open(path(VECTORED_READ_FILE_NAME))) {
+ in.readVectored(fileRanges, allocate);
+ validateVectoredReadResult(fileRanges);
+ }
+ }
+
+ /**
+ * As the minimum seek value is 4*1024, the first three ranges will be
+ * merged into and other two will remain as it is.
+ */
+ @Test
+ public void testSomeRangesMergedSomeUnmerged() throws Exception {
+ FileSystem fs = getFileSystem();
+ List<FileRange> fileRanges = new ArrayList<>();
+ fileRanges.add(new FileRangeImpl(8*1024, 100));
+ fileRanges.add(new FileRangeImpl(14*1024, 100));
+ fileRanges.add(new FileRangeImpl(10*1024, 100));
+ fileRanges.add(new FileRangeImpl(2 *1024 - 101, 100));
+ fileRanges.add(new FileRangeImpl(40*1024, 1024));
+ try (FSDataInputStream in = fs.open(path(VECTORED_READ_FILE_NAME))) {
+ in.readVectored(fileRanges, allocate);
+ validateVectoredReadResult(fileRanges);
+ }
+ }
+
+ @Test(timeout = 1800000)
+ public void testSameRanges() throws Exception {
+ FileSystem fs = getFileSystem();
+ List<FileRange> fileRanges = new ArrayList<>();
+ fileRanges.add(new FileRangeImpl(8*1024, 1000));
+ fileRanges.add(new FileRangeImpl(8*1024, 1000));
+ fileRanges.add(new FileRangeImpl(8*1024, 1000));
+ try (FSDataInputStream in = fs.open(path(VECTORED_READ_FILE_NAME))) {
Review comment:
yeah there was already one, adding in one more.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 713622)
Time Spent: 11h 50m (was: 11h 40m)
> 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: Mukund Thakur
> Priority: Major
> Labels: performance, pull-request-available
> Time Spent: 11h 50m
> 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.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
