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

Jakob Homan commented on HDFS-1751:
-----------------------------------

A quota by any other name would still limit the number of objects that can be 
created in the namespace just as sweetly.  

The following code from the patch is very telling:
{code}   private <T extends INode> T addChild(INode[] pathComponents, int pos,
       T child, long childDiskspace, boolean inheritPermission,
       boolean checkQuota) throws QuotaExceededException {
+       // The filesystem limits are not really quotas, so this check may appear
+       // odd.  It's because a rename operation deletes the src, tries to add
+       // to the dest, if that fails, re-adds the src from whence it came.
+       // The rename code disables the quota when it's restoring to the
+       // original location becase a quota violation would cause the the item
+       // to go "poof".  The fs limits must be disabled for the same reason.
{code}

Essentially it's saying we're not doing quota checking, except that we're 
throwing a FSLimitException (which extends and is therefore a 
QuotaExceededException) and we have to do the exact same workaround that the 
quota check has to do in this situation - but we're still not a quota check.  

bq. after a couple of incidents where user applications exhausted some resource 
by behaving in a way that was deeply wrong and (probably) unintended.
Could these incidents have been prevented by judicious use of the existing 
namespace quota?

My concern remains that this quota is implemented separately and in parallel 
from the main quota checking mechanism, adding more state, more paths and more 
opportunity for bugs.  Could we accomplish the same thing by defining a default 
NSQuota for new directories and allowing this to be specified via configuration 
file or command line (as with the other quotas)?  

I'm -1 on this patch as it stands.

> 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.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

Reply via email to