Return-Path: X-Original-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Delivered-To: apmail-hadoop-hdfs-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3CF33C5A9 for ; Fri, 4 May 2012 14:15:40 +0000 (UTC) Received: (qmail 21876 invoked by uid 500); 4 May 2012 14:15:39 -0000 Delivered-To: apmail-hadoop-hdfs-user-archive@hadoop.apache.org Received: (qmail 21817 invoked by uid 500); 4 May 2012 14:15:39 -0000 Mailing-List: contact hdfs-user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hdfs-user@hadoop.apache.org Delivered-To: mailing list hdfs-user@hadoop.apache.org Received: (qmail 21805 invoked by uid 99); 4 May 2012 14:15:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 May 2012 14:15:39 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [206.112.75.238] (HELO iron-u-a-out.osis.gov) (206.112.75.238) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 May 2012 14:15:31 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0GAGHjo0+sEAbx/2dsb2JhbABFoRUBkUWBD4IAgScBB10TBSPDLoJUjjkElX6TRg X-IronPort-AV: E=Sophos;i="4.75,531,1330923600"; d="scan'208";a="9023702" Received: from ghost-a.center.osis.gov (HELO mail-vb0-f48.google.com) ([172.16.6.241]) by iron-u-a-in.osis.gov with ESMTP/TLS/RC4-SHA; 04 May 2012 10:13:51 -0400 Received: by vbjk17 with SMTP id k17so3211415vbj.35 for ; Fri, 04 May 2012 07:15:07 -0700 (PDT) Received: by 10.52.68.35 with SMTP id s3mr3130179vdt.117.1336140907738; Fri, 04 May 2012 07:15:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Fri, 4 May 2012 07:14:47 -0700 (PDT) From: John Vines Date: Fri, 4 May 2012 10:14:47 -0400 Message-ID: Subject: Question regarding FSDataOutputStream.close() behavior To: hdfs-user Content-Type: multipart/alternative; boundary=20cf3071c7442cf77804bf368c39 --20cf3071c7442cf77804bf368c39 Content-Type: text/plain; charset=ISO-8859-1 So I'm trying to figure out the behavior of calling DFSOutputStream.close(), as well as if/which version it changed in. I see in the javadocs that the complete call (which close calls) will not return until "all the file's * blocks have been replicated the minimum number of times". Is the minimum number dfs.replication.min, or is it the files number of replications? Regardless of that answer, I'm curious when the behavior changed, if it hadn't been like that. I remember it used to be that it would utilize lazy replication, though that may just be for bringing underreplicated blocks up to snuff. Any insight would be appreciated. --20cf3071c7442cf77804bf368c39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So I'm trying to figure out the behavior of calling=20 DFSOutputStream.close(), as well as if/which version it changed in. I see i= n the=20 javadocs that the complete call (which close calls) will not return=20 until "all the file's=A0 * blocks have been replicated the minimum= number=20 of times".=A0 Is the minimum number dfs.replication.min, or is it the= =20 files number of replications?

Regardless of that answer, I'm curious when the behavior changed, i= f it hadn't been like that. I remember it used to be that it would=20 utilize lazy replication, though that may just be for bringing=20 underreplicated blocks up to snuff. Any insight would be appreciated. --20cf3071c7442cf77804bf368c39--