HDDS-12918. OM support byte range GET#10166
Conversation
Gargi-jais11
left a comment
Gargi-jais11
left a comment
There was a problem hiding this comment.
Thanks @ivandika3 for the patch.
Please find inlined review comments
peterxcli
left a comment
peterxcli
left a comment
There was a problem hiding this comment.
Thanks @ivandika3 for the patch, I'm looking if we could remove the setByteRangeStartOffset, calculate the start offset at s3g side, it take the first block of block list and use the range info from header to calculate the offset, then use the result as input stream's seek offset
| * @return {@link OzoneKey} | ||
| * @throws IOException | ||
| */ | ||
| default OzoneKeyDetails getS3KeyDetails(String bucketName, String keyName, |
There was a problem hiding this comment.
why there is a implementation?
There was a problem hiding this comment.
this should sit in ClientProtocolStub.
There was a problem hiding this comment.
This exists as part of a client-side compatibility for other clients that implements ClientProtocol, but it's not RpcClient. If getS3KeyDetails API is called on older implementation (that does not have a concrete implementation of getS3KeyDetails) without, the API call will not work since it does not have any concrete implementation.
However, I think we can safely assume that only RpcClient implements ClientProtocol as Ozone is not a library per se (in contrast to Hadoop FileSystem interface which is extended depending on different backing store).
| // Byte range requested by S3 GET. OM uses it to return only the | ||
| // key locations needed to satisfy the read. | ||
| optional uint64 byteRangeStart = 25; | ||
| optional uint64 byteRangeEnd = 26; |
There was a problem hiding this comment.
How about introducing a common msg, I remember few DN-SCM pb messages have range concept, maybe we could reuse theirs?
message ByteRange {
// Inclusive start and end offsets: [start, end].
optional uint64 start = 1;
optional uint64 end = 2;
}
message KeyArgs {
// ...
optional ByteRange byteRange = 25;
}| keyArgs.getForceUpdateContainerCacheFromSCM()) | ||
| .setMultipartUploadPartNumber(keyArgs.getMultipartNumber()) | ||
| .build(); | ||
| if (keyArgs.hasByteRangeStart() && keyArgs.hasByteRangeEnd()) { |
There was a problem hiding this comment.
could become
| if (keyArgs.hasByteRangeStart() && keyArgs.hasByteRangeEnd()) { | |
| if (keyArgs.hasByteRange()) { |
if we introduce new range message.
https://github.com/apache/ozone/pull/10166/changes#r3180692841
| OzoneKeyDetails rangedKeyDetails = getClientProtocol() | ||
| .getS3KeyDetails(bucketName, keyPath, partNumber, startOffset, | ||
| endOffset); |
There was a problem hiding this comment.
This is a correctness issue, we should not call getS3KeyDetails multiple times within a single S3 call since the latter getS3KeyDetails might not return the same key as the first (i.e. there is a key overwrite in between).
The reason of the current multiple getS3KeyDetails is that the first getS3KeyDetails need to be used to get the key length for range header validation. Therefore, we need to push this range validation to OM.
Addressing this.
|
This PR has been marked as stale due to 21 days of inactivity. Please comment or remove the stale label to keep it open. Otherwise, it will be automatically closed in 7 days. |
|
This PR has been marked as stale due to 21 days of inactivity. Please comment or remove the stale label to keep it open. Otherwise, it will be automatically closed in 7 days. |
|
Thank you for your contribution. This PR is being closed due to inactivity. Please contact a maintainer if you would like to reopen it. |
3 participants
What changes were proposed in this pull request?
Similar to HDDS-11699, we can move the byte range GET filter from S3G to the OM so that the network and serialization cost can be reduced for objects with a lot of blocks.
Applications like JuiceFS on S3 uses quite a bit of byte range fetch.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-12918
How was this patch tested?
UT, IT.