hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-4437) Clients should not retain leases on moved files
Date Thu, 24 Jan 2013 23:27:13 GMT

    [ https://issues.apache.org/jira/browse/HDFS-4437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13562127#comment-13562127

Daryn Sharp commented on HDFS-4437:

I don't think HDFS-4258 fixes the case of a daemon being left with "leaked" leases on renamed
files.  Ex. a daemon is busy writing files, let's say logs, and someone comes along and moves
them.  The daemon will still have a lease on the renamed files, but has absolutely no idea
where those files are now.  There is no way for the daemon to close the broken streams so
the files can't be removed from the lease.  So the daemon opens new logs and chugs along.
 Since it's busy writing to at least one file in its lease, the lease won't expire, so the
renamed files remain locked "forever".

Actually, come to think of it, isn't the issue in HDFS-4258 much more simply fixed by releasing
the leases?
> Clients should not retain leases on moved files
> -----------------------------------------------
>                 Key: HDFS-4437
>                 URL: https://issues.apache.org/jira/browse/HDFS-4437
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: namenode
>    Affects Versions: 0.23.0, 2.0.0-alpha, 3.0.0
>            Reporter: Daryn Sharp
>            Assignee: Daryn Sharp
>            Priority: Critical
> Moving open files and/or parent directories of open files will rewrite the leases to
the new path.  The client is not notified so future stream operations will fail.  However,
as long as the client keeps its lease active it will have a "lock" on the file in its new
location.  This is not good for a daemon.
> Leases should be released after the file is moved.

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

View raw message