hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-6294) Use INode IDs to avoid conflicts when a file open for write is renamed
Date Tue, 29 Apr 2014 17:20:25 GMT

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

Colin Patrick McCabe commented on HDFS-6294:

bq. There was a lengthy discussion on this when inode id was added and, IIRC, allowing writes
to continue after rename (of itself or one of ancestor dir) was thought to be the way we were
heading. After all, true inode-based file systems work similarly. One difference would be
delete, after which no block allocation is allowed.

Yeah.  This will make us more compatible with other filesystems.  Nearly all filesystems support
write after rename.  And certainly it helps with NFS support.

bq. It will be nice if we can make it purely inode/inode id based. Rename won't cause any
updates in LeaseManager. Deletion of a large tree might be less efficient, but there may be
a way to speed it up.

Recursive deletion needs to recurse into all inodes anyway.  So we could just put the lease
object into {{FileUnderConstructionFeature}} and avoid any kind of external lookup.  I would
prefer to do this in a follow-up change, since it will make the patches smaller.

> Use INode IDs to avoid conflicts when a file open for write is renamed
> ----------------------------------------------------------------------
>                 Key: HDFS-6294
>                 URL: https://issues.apache.org/jira/browse/HDFS-6294
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: namenode
>    Affects Versions: 0.20.1
>            Reporter: Colin Patrick McCabe
>            Assignee: Colin Patrick McCabe
>         Attachments: HDFS-6294.001.patch
> Now that we have a unique INode ID for each INode, clients with files that are open for
write can use this unique ID rather than a file path when they are requesting more blocks
or closing the open file.  This will avoid conflicts when a file which is open for write is
renamed, and another file with that name is created.

This message was sent by Atlassian JIRA

View raw message