Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 23 Nov 2016 12:03:58 +0000 (UTC)
From: "Steve Loughran (JIRA)" <jira@apache.org>
To: common-dev@hadoop.apache.org
Message-ID: <JIRA.13022837.1479902601000.349989.1479902638390@Atlassian.JIRA>
In-Reply-To: <JIRA.13022837.1479902601000@Atlassian.JIRA>
References: <JIRA.13022837.1479902601000@Atlassian.JIRA> <JIRA.13022837.1479902601693@arcas>
Subject: [jira] [Created] (HADOOP-13829) S3A getContentSummary to use flat
 listFiles instead of treewalk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 23 Nov 2016 12:04:00 -0000

Steve Loughran created HADOOP-13829:
---------------------------------------

             Summary: S3A getContentSummary to use flat listFiles instead of treewalk
                 Key: HADOOP-13829
                 URL: https://issues.apache.org/jira/browse/HADOOP-13829
             Project: Hadoop Common
          Issue Type: Sub-task
          Components: fs/s3
    Affects Versions: 2.8.0
            Reporter: Steve Loughran
            Priority: Minor


FS shell {{-count}} uses {{getContentSummary}}  to summarise the contents; this slows significantly with directory tree depth. On wide directories, as the FileStatus[] array is built up before recursing down, if there are many millions of files, memory use becomes an issue


Moving to a flat listFiles listing with iterator-based scanning would allow directory depth to become a near-non-issue, avoid memory problems. We'd need to reverse-construct the directory tree for its count summary; some hash map of parent paths could build that up while iterating through the files and adding up their sizes


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org