[
https://issues.apache.org/jira/browse/HDDS-16166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Andika updated HDDS-16166:
-------------------------------
Description:
This is an open discussion, need feedback.
I noticed that ScmBlockLocationProtocol allocateBlock Javadoc does not have any
guarantee on the List<AllocatedBlock> returned and when to throw exception.
This is an important API and we should clarify the contract in greater detail
so that the client and implementers know the contract deeply.
These are the discussion points
* Does the returned List<AllocateBlock> size need to be equal to the "num"
parameter?
** Currently, it does not seem to be since BlockManagerImpl#allocateBlock can
return null if there is no container and SCMBlockProtocolServer simply skip
this block
** So there is a possibility where an allocateBlock asking for 2 blocks might
return <2 (0 / 1) blocks.
** Is this a reasonable contract? Or should we throw exception if we can only
allocate blocks less than the specified "num"
*** In Ozone case, it might be fine since the BlockOutputStream would try to
call OmAllocateBlockRequest if we have less than the required block
*** However, if we think HDDS as a block service (ignore all other Ozone
specific logic), this does not seem to make sense since client need some kind
of guarantee that the requested block should be respected. If not, then the
client need to implement some retry logic until it has the required blocks,
which is not user friendly.
* Does each container in AllocatedBlock in List<AllocatedBlock> definitely
reserve the "size" for client, or will there be a possibility where the
AllocatedBlock is pointing to a container that is already full?
** This is more one the space accounting part
I will document this.
was:
This is an open discussion, need feedback.
I noticed that ScmBlockLocationProtocol allocateBlock Javadoc does not have any
guarantee on the List<AllocatedBlock> returned and when to throw exception.
This is an important API and we should clarify the contract in greater detail
so that the client and implementers know the contract deeply.
These are the discussion points
* Does the returned List<AllocateBlock> size need to be equal to the "num"
parameter?
** Currently, it does not seem to be since BlockManagerImpl#allocateBlock can
return null if there is no container and SCMBlockProtocolServer simply skip
this block
** So there is a possibility where an allocateBlock asking for 2 blocks might
return <2 (0 / 1) blocks.
** Is this a reasonable contract? Or should we throw exception if we can only
allocate blocks less than the specified "num"
*** In Ozone case, it might be fine since the BlockOutputStream would try to
call OmAllocateBlockRequest if we have less than the required block
* Does each container in AllocatedBlock in List<AllocatedBlock> definitely
reserve the "size" for client, or will there be a possibility where the
AllocatedBlock is pointing to a container that is already full?
** This is more one the space accounting part
I will document this.
> Clarify the allocateBlock contracts
> -----------------------------------
>
> Key: HDDS-16166
> URL: https://issues.apache.org/jira/browse/HDDS-16166
> Project: Apache Ozone
> Issue Type: Improvement
> Reporter: Ivan Andika
> Assignee: Ivan Andika
> Priority: Major
>
> This is an open discussion, need feedback.
> I noticed that ScmBlockLocationProtocol allocateBlock Javadoc does not have
> any guarantee on the List<AllocatedBlock> returned and when to throw
> exception.
> This is an important API and we should clarify the contract in greater detail
> so that the client and implementers know the contract deeply.
> These are the discussion points
> * Does the returned List<AllocateBlock> size need to be equal to the "num"
> parameter?
> ** Currently, it does not seem to be since BlockManagerImpl#allocateBlock
> can return null if there is no container and SCMBlockProtocolServer simply
> skip this block
> ** So there is a possibility where an allocateBlock asking for 2 blocks
> might return <2 (0 / 1) blocks.
> ** Is this a reasonable contract? Or should we throw exception if we can
> only allocate blocks less than the specified "num"
> *** In Ozone case, it might be fine since the BlockOutputStream would try to
> call OmAllocateBlockRequest if we have less than the required block
> *** However, if we think HDDS as a block service (ignore all other Ozone
> specific logic), this does not seem to make sense since client need some kind
> of guarantee that the requested block should be respected. If not, then the
> client need to implement some retry logic until it has the required blocks,
> which is not user friendly.
> * Does each container in AllocatedBlock in List<AllocatedBlock> definitely
> reserve the "size" for client, or will there be a possibility where the
> AllocatedBlock is pointing to a container that is already full?
> ** This is more one the space accounting part
> I will document this.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
