Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Mon, 11 Apr 2011 18:46:06 +0000 (UTC)
From: "John George (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: 
 <123089691.50021.1302547566059.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1024545672.871.1300114349811.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HDFS-1751) Intrinsic limits for HDFS files,
 directories
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

John George commented on HDFS-1751:
-----------------------------------

The code look pretty good to me.

"name" in "dfs.namenode.fs-limits.max-component-length" is added multiple times in hdfs-default.xml.

Like we discussed offline, I had a comment as to whether pathComponents[pos-1] in verifyFsLimits can ever be the root inode, but like you said - since this is in "addChild" routine, it always has atleast one parent and so "pos-1" is valid.

As a whole, the code looks like its doing what you describe it should do.

> Intrinsic limits for HDFS files, directories
> --------------------------------------------
>
>                 Key: HDFS-1751
>                 URL: https://issues.apache.org/jira/browse/HDFS-1751
>             Project: Hadoop HDFS
>          Issue Type: New Feature
>          Components: data-node
>    Affects Versions: 0.22.0
>            Reporter: Daryn Sharp
>            Assignee: Daryn Sharp
>             Fix For: 0.23.0
>
>         Attachments: HDFS-1751-2.patch, HDFS-1751-3.patch, HDFS-1751-4.patch, HDFS-1751-5.patch, HDFS-1751.patch
>
>
> Enforce a configurable limit on:
>   the length of a path component
>   the number of names in a directory
> The intention is to prevent a too-long name or a too-full directory. This is not about RPC buffers, the length of command lines, etc. There may be good reasons for those kinds of limits, but that is not the intended scope of this feature. Consequently, a reasonable implementation might be to extend the existing quota checker so that it faults the creation of a name that violates the limits. This strategy of faulting new creation evades the problem of existing names or directories that violate the limits.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira