[
https://issues.apache.org/jira/browse/HDFS-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Nauroth updated HDFS-5203:
--------------------------------
Attachment: HDFS-5203.2.patch
bq. We got rid of the batch operations because they were a big headache in
general.
I missed this discussion, but I do think it makes sense. There was a lot of
logic in my first patch around checking the permissions across the union of all
pools. I went down this path initially to prevent a lot of chatter on RPC and
edit log ops, but that might be a premature optimization. We expect far fewer
cache directives than other namesystem objects.
I'm attaching version 2 of the patch with the simpler approach. Tests are
still forthcoming.
> Concurrent clients that add a cache directive on the same path may
> prematurely uncache from each other.
> -------------------------------------------------------------------------------------------------------
>
> Key: HDFS-5203
> URL: https://issues.apache.org/jira/browse/HDFS-5203
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: HDFS-4949
> Reporter: Chris Nauroth
> Assignee: Chris Nauroth
> Attachments: HDFS-5203.1.patch, HDFS-5203.2.patch
>
>
> When a client adds a cache directive, we assign it a unique ID and return
> that ID to the client. If multiple clients add a cache directive for the
> same path, then we return the same ID. If one client then removes the cache
> entry for that ID, then it is removed for all clients. Then, when this
> change becomes visible in subsequent cache reports, the datanodes may
> {{munlock}} the block before the other clients are done with it.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
