[
https://issues.apache.org/jira/browse/HDFS-12751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284780#comment-16284780
]
Nanda kumar commented on HDFS-12751:
------------------------------------
You’re right Chen.ContainerMapping is the one which maintains container.db,
ContainerStateManager is purely an in-memory state representation.
bq. But appears to me that this is what BlockManager perceives as the bytes
that might get allocated, not necessarily the actual allocated bytes on the
container. e.g. client may then terminate before talking to container etc.
This is the reason why we have two fields in {{ContainerInfo}} for tracking the
usage, one is {{allocatedBytes}} which represents the number of bytes allocated
by SCM to the clients, the second one is {{usedBytes}} which will give the
amount of data written into the container.
{{allocatedBytes}} is updated by {{ContainerStateManager}} in
{{getMatchingContainer}} call, the in-memory map
{{ContainerStateManager#containers}} maintains the updated value. The updated
{{ContainerInfo}} is not stored in the {{container.db}},
{{ContainerStateManager}} doesn’t write to {{container.db}}.
{{usedBytes}} is updated through container report in
{{ContainerMapping#processContainerReports}} which is also persisted in
{{container.db}}. Here we don’t have access to the current {{allocatedBytes}}
value. We retain the old {{allocatedBytes}} value in db.
As far as {{ContainerStateManager#updateContainerState}} is concerned, we make
this call only when we want to do container state change, like ALOCATED
->CREATING -> OPEN -> CLOSE. Even in this case we are reading
{{allocatedBytes}} from {{container.db}} which is not the latest one.
The below code of setting {{allocatedBytes}} is not correct.
{code}
ContainerInfo containerInfo = new ContainerInfo.Builder()
.setContainerName(info.getContainerName())
.setState(newState)
.setPipeline(info.getPipeline())
.setAllocatedBytes(info.getAllocatedBytes()) <— This is wrong, we
should not get allocatedBytes from info object.
.setUsedBytes(info.getUsedBytes())
.setNumberOfKeys(info.getNumberOfKeys())
.setStateEnterTime(Time.monotonicNow())
.setOwner(info.getOwner())
.build();
{code}
bq. And block report is the trigger of the updateContainerState code path.
We call updateContainerState during container report processing only if the
container usage reaches {{containerCloseThreshold}} and we want to close the
container, otherwise we don’t call
{{ContainerStateManager#updateContainerState}}
bq. I feel that persisting the number we got from updateContainerState is
already the better thing.
We want to persist both {{allocatedBytes}} and {{usedBytes}}. Proper value
usedBytes is already getting persisted, this jira is to do the same for
allocatedBytes.
bq. Seems to me that we should keep this abstraction, leave
{{ContainerStateManager}} away from container.db and only let ContainerMapping
do the container metadata management.
I agree, in that case we have to expose a method in {{ContainerStateManager}}
for getting all the open containers. In {{ContainerManager#close}} we need to
make sure that we update all the open container’s {{allocatedBytes}}, by
getting the correct value from {{ContainerStateManager}}.
> Ozone: SCM: update container allocated size to container db for all the open
> containers in ContainerStateManager#close
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-12751
> URL: https://issues.apache.org/jira/browse/HDFS-12751
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ozone
> Reporter: Nanda kumar
> Assignee: Chen Liang
>
> Container allocated size is maintained in memory by
> {{ContainerStateManager}}, this has to be updated in container db when we
> shutdown SCM. {{ContainerStateManager#close}} will be called during SCM
> shutdown, so updating allocated size for all the open containers should be
> done here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
