impala-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sailesh Mukil (Code Review)" <>
Subject [Impala-ASF-CR] IMPALA-5378: Disk IO manager needs to understand ADLS
Date Wed, 31 May 2017 22:38:54 GMT
Sailesh Mukil has posted comments on this change.

Change subject: IMPALA-5378: Disk IO manager needs to understand ADLS

Patch Set 1:


 > questions:
 > - what about insert staging for adls (in

ADLS claims to have atomic renames. So we don't need to worry about that like we did for S3.

 > - what about hdfs-fs-cache, does that need to be extended?

I'm not sure which cache you mean, so I'll address both. The file handle cache at this point
doesn't support caching remote file handles. Also, we don't support SET CACHED for S3 and
ADLS at this point.
File be/src/runtime/

Line 402:   // ADLS uses buffer sizes of 4k. Given that, and the above JNI array allocation
> you mean multiples of 4k?
I should have researched this a little better, I used 4k based on some misinformation. It
looks like the buffer size used is 4MB according to this:

Also noticed a Hadoop JIRA which mentions better performance with higher buffer sizes:

The pro of using a buffer size of 4M is obviously to be aligned with ADLS and avoid fragmentation.

The con however, is that we'd spend considerably more CPU allocating the JNI byte buffer and
also doing the memcpy.

What do you think would be better to settle for?
File be/src/runtime/disk-io-mgr.h:

Line 764:   int RemoteADLSDiskId() const { return num_local_disks() + REMOTE_ADLS_DISK_OFFSET;
> RemoteAdlsDiskId

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: I067f053fec941e3631610c5cc89a384f257ba906
Gerrit-PatchSet: 1
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-Owner: Sailesh Mukil <>
Gerrit-Reviewer: Marcel Kornacker <>
Gerrit-Reviewer: Sailesh Mukil <>
Gerrit-HasComments: Yes

View raw message