Return-Path: Delivered-To: apmail-hadoop-core-dev-archive@www.apache.org Received: (qmail 13860 invoked from network); 3 Jun 2008 20:55:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Jun 2008 20:55:08 -0000 Received: (qmail 3348 invoked by uid 500); 3 Jun 2008 20:55:09 -0000 Delivered-To: apmail-hadoop-core-dev-archive@hadoop.apache.org Received: (qmail 3092 invoked by uid 500); 3 Jun 2008 20:55:08 -0000 Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: core-dev@hadoop.apache.org Delivered-To: mailing list core-dev@hadoop.apache.org Received: (qmail 3081 invoked by uid 99); 3 Jun 2008 20:55:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jun 2008 13:55:08 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Jun 2008 20:54:28 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 520E3234C134 for ; Tue, 3 Jun 2008 13:54:45 -0700 (PDT) Message-ID: <777488709.1212526485335.JavaMail.jira@brutus> Date: Tue, 3 Jun 2008 13:54:45 -0700 (PDT) From: "Tom White (JIRA)" To: core-dev@hadoop.apache.org Subject: [jira] Updated: (HADOOP-3095) Validating input paths and creating splits is slow on S3 In-Reply-To: <2085212560.1206552690774.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HADOOP-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom White updated HADOOP-3095: ------------------------------ Status: Patch Available (was: In Progress) > Validating input paths and creating splits is slow on S3 > -------------------------------------------------------- > > Key: HADOOP-3095 > URL: https://issues.apache.org/jira/browse/HADOOP-3095 > Project: Hadoop Core > Issue Type: Improvement > Components: fs, fs/s3 > Reporter: Tom White > Assignee: Tom White > Fix For: 0.18.0 > > Attachments: faster-job-init.patch, hadoop-3095-v2.patch, hadoop-3095-v3.patch, hadoop-3095-v4.patch, hadoop-3095.patch > > > A call to listPaths on S3FileSystem results in an S3 access for each file in the directory being queried. If the input contains hundreds or thousands of files this is prohibitively slow. This method is called in FileInputFormat.validateInput and FileInputFormat.getSplits. This would be easy to fix by overriding listPaths (all four variants) in S3FileSystem to not use listStatus which creates a FileStatus object for each subpath. However, listPaths is deprecated in favour of listStatus so this might be OK as a short term measure, but not longer term. > But it gets worse: FileInputFormat.getSplits goes on to access S3 a further six times for each input file via these calls: > 1. fs.isDirectory > 2. fs.exists > 3. fs.getLength > 4. fs.getLength > 5. fs.exists (from fs.getFileBlockLocations) > 6. fs.getBlockSize > So it would be best to change getSplits to use listStatus, and only access S3 once for each file. (This would help HDFS too.) This change would require some care since FileInputFormat has a protected method listPaths which subclasses can override (although, in passing I notice validateInput doesn't use listPaths - is this a bug?). > For input validation, one approach would be to disable it for S3 by creating a custom FileInputFormat. In this case, missing files would be detected during split generation. Alternatively, it may be possible to cache the input paths between validateInput and getSplits. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.