[
https://issues.apache.org/jira/browse/HDFS-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468927#comment-13468927
]
Colin Patrick McCabe commented on HDFS-2551:
--------------------------------------------
bq. There's no way to do our own reference counting? (ie we don't have any clue
when an fd gets duped?).
FUSE doesn't give us that info.
I did start out on a patch to add a file name -> hdfsFile cache in fuse_dfs a
few weeks ago, but it started getting really complex (cache invalidation is not
easy.) Also, it doesn't really solve the problem 100%. I could have code like
this:
{code}
computer A | computer B
============================+==========================
fd = open(FILE_NAME) |
write(fd, ...) |
close(fd) |
send-RPC-to-remote-PC |
| receive RPC
| open(fd, FILE_NAME) => error, already open
[actual fuse release] |
{code}
> fuse-dfs's close() is asynchronous
> ----------------------------------
>
> Key: HDFS-2551
> URL: https://issues.apache.org/jira/browse/HDFS-2551
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: fuse-dfs
> Affects Versions: 0.20.205.0, 0.23.0
> Reporter: Todd Lipcon
>
> FUSE's "release" operation is called asynchronously when a file is closed
> from userspace. This means that, if a program writes a file, closes it, and
> immediately re-opens it, it might not succeed. We should figure out some
> workaround or trick to make close synchronous, if possible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
