You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "Todd Lipcon (Created) (JIRA)" <ji...@apache.org> on 2011/11/11 23:08:51 UTC
[jira] [Created] (HDFS-2551) fuse-dfs's close() is asynchronous
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: contrib/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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2551) fuse-dfs's close() is asynchronous
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468908#comment-13468908 ]
Todd Lipcon commented on HDFS-2551:
-----------------------------------
ah, I see. Then this seems like it might be a reasonable workaround. There's no way to do our own reference counting? (ie we don't have any clue when an fd gets duped?)
> 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
[jira] [Commented] (HDFS-2551) fuse-dfs's close() is asynchronous
Posted by "Todd Lipcon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468882#comment-13468882 ]
Todd Lipcon commented on HDFS-2551:
-----------------------------------
bq. One way to fix this would be to call hdfsClose in the fuse flush() method
This would be way too slow -- shutting down and reconstructing the pipeline, multiple round trips to NN, etc. flush() is used for applications like WALs which would kill performance here
> 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
[jira] [Commented] (HDFS-2551) fuse-dfs's close() is asynchronous
Posted by "Todd Lipcon (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13148778#comment-13148778 ]
Todd Lipcon commented on HDFS-2551:
-----------------------------------
http://sourceforge.net/mailarchive/forum.php?thread_name=87wslu4dq9.fsf%40frosties.localdomain&forum_name=fuse-devel is the thread in which the fuse people say that {{release}} is async.
> 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: contrib/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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HDFS-2551) fuse-dfs's close() is asynchronous
Posted by "Colin Patrick McCabe (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (HDFS-2551) fuse-dfs's close() is asynchronous
Posted by "Colin Patrick McCabe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468847#comment-13468847 ]
Colin Patrick McCabe commented on HDFS-2551:
--------------------------------------------
To add more detail here:
Every time you call close() on a FUSE file descriptor, the FUSE flush() method is called synchronously. That method calls hsync(), which will make the file visible in the HDFS namespace.
When there are no more file descriptors left referring to the open file, it is put in a queue, so that the FUSE release() function can be run asychronously at some later time.
So if you have code like this:
{code}
fd = open(NAME, ...)
write(fd, ...)
close(fd)
fd2 = open(NAME, ...)
{code}
Chances are that the second open will fail because the underlying HDFS file is still open.
One way to fix this would be to call hdfsClose in the fuse flush() method. Then, if the file still needed to be written to after that, we'd have to re-open it using append. This would also have the beneficial effect of removing an unecessary call to hdfsFlush in the common case.
> 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
[jira] [Commented] (HDFS-2551) fuse-dfs's close() is asynchronous
Posted by "Colin Patrick McCabe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HDFS-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468903#comment-13468903 ]
Colin Patrick McCabe commented on HDFS-2551:
--------------------------------------------
bq. This would be way too slow – shutting down and reconstructing the pipeline, multiple round trips to NN, etc. flush() is used for applications like WALs which would kill performance here
I realize it's fairly confusing, since we have about a zillion things called flush at this point.
However, in this case, I'm not talking about doing it in hdfsFlush, I'm talking about the fuse flush() method, as described here:
{code}
/** Possibly flush cached data
*
* BIG NOTE: This is not equivalent to fsync(). It's not a
* request to sync dirty data.
*
* Flush is called on each close() of a file descriptor. So if a
* filesystem wants to return write errors in close() and the file
* has cached dirty data, this is a good place to write back data
* and return any errors. Since many applications ignore close()
* errors this is not always useful.
*
* NOTE: The flush() method may be called more than once for each
* open(). This happens if more than one file descriptor refers
* to an opened file due to dup(), dup2() or fork() calls. It is
* not possible to determine if a flush is final, so each flush
* should be treated equally. Multiple write-flush sequences are
* relatively rare, so this shouldn't be a problem.
*
* Filesystems shouldn't assume that flush will always be called
* after some writes, or that if will be called at all.
*
* Changed in version 2.2
*/
int (*flush) (const char *, struct fuse_file_info *);
{code}
In the extremely common case, where you open a file, write stuff, and close, you only get one call to {{flush}}. If you start calling {{dup}}, {{dup2}}, or {{fork}}, then you can get multiple FUSE flushes.
> 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