Return-Path: 
 <user-return-6798-apmail-hadoop-mapreduce-user-archive=hadoop.apache.org@hadoop.apache.org>
X-Original-To: apmail-hadoop-mapreduce-user-archive@minotaur.apache.org
Delivered-To: apmail-hadoop-mapreduce-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 55001106FC
	for <apmail-hadoop-mapreduce-user-archive@minotaur.apache.org>;
 Sun,  7 Apr 2013 13:10:51 +0000 (UTC)
Received: (qmail 90546 invoked by uid 500); 7 Apr 2013 13:10:46 -0000
Delivered-To: apmail-hadoop-mapreduce-user-archive@hadoop.apache.org
Received: (qmail 90407 invoked by uid 500); 7 Apr 2013 13:10:46 -0000
Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@hadoop.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@hadoop.apache.org>
List-Post: <mailto:user@hadoop.apache.org>
List-Id: <user.hadoop.apache.org>
Reply-To: user@hadoop.apache.org
Delivered-To: mailing list user@hadoop.apache.org
Received: (qmail 90358 invoked by uid 99); 7 Apr 2013 13:10:45 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 07 Apr 2013 13:10:45 +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: domain of linlma@gmail.com designates
 209.85.128.41 as permitted sender)
Received: from [209.85.128.41] (HELO mail-qe0-f41.google.com) (209.85.128.41)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 07 Apr 2013 13:10:39 +0000
Received: by mail-qe0-f41.google.com with SMTP id b10so1429938qen.14
        for <user@hadoop.apache.org>; Sun, 07 Apr 2013 06:10:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:x-received:date:message-id:subject:from:to
         :content-type;
        bh=OHPP9tA2VNtvjVGA3seXbUsCVZd/E5Mgx5F0X+8DnIA=;
        b=GOViRXBprjSJr6AHAKuX2eP9pRlTZbuj147G9d6ocdSQe3mYMu/oCp2f0A1XKC3ozj
         k115hPyjLb6cL4x2ztfYBZnhQHB9WSOBr8+xGhsry6ApYXBQS6aNZpxK5GIlzxwjdfJ4
         AsrqeR6Ic1+khhGQbNkv2/FivYJbv7acCKoAIPCBLdWL73rM6Oxy8/ksqHAl0xri0xov
         upQ9ev+vaBdGTTDIMa13sEAxx1T82rNYBfS6UXVAOI8YbNayOtJx/Nmm5ySFZvceEQeO
         jd7VXPmpPMr0iXjPDfKl3GH2w7YWJdOtMDHRZEeQy6ZSNq+4cXqmuhaKwaK9ouVNKYNE
         ZEkw==
MIME-Version: 1.0
X-Received: by 10.229.103.85 with SMTP id j21mr1528188qco.65.1365340219212;
 Sun, 07 Apr 2013 06:10:19 -0700 (PDT)
Received: by 10.49.50.2 with HTTP; Sun, 7 Apr 2013 06:10:19 -0700 (PDT)
Date: Sun, 7 Apr 2013 21:10:19 +0800
Message-ID: 
 <CAK_MoSscB5s7H6mhSrp83crgPsTHHkz2yfc7SjAQRHcHkqHqEA@mail.gmail.com>
Subject: copy-on-write used in Hadoop file system upgrade
From: Lin Ma <linlma@gmail.com>
To: user@hadoop.apache.org
Content-Type: multipart/alternative; boundary=001517573734c3a59a04d9c50a42
X-Virus-Checked: Checked by ClamAV on apache.org

--001517573734c3a59a04d9c50a42
Content-Type: text/plain; charset=ISO-8859-1

Hi guys,

I am reading from there for Hadoop handles file system upgrade (
http://www.storageconference.org/2010/Papers/MSST/Shvachko.pdf), it is
mentioned, "and block modifications during appends use the copy on write
technique",

   - I think it means old and new file system will keep only one copy using
   hard link to save space as long as the file has no change, and if during
   upgrade, the file changed (during append operation), then a new updated
   file will be created in order to save space. I am not sure if my
   understanding is correct?
   - Another question is, copy-on-write only used to save space for keeping
   snapshot information during file system upgrade? Or it has more broad use
   cases in HDFS?


regards,
Lin

--001517573734c3a59a04d9c50a42
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi guys,<br><br>I am reading from there for Hadoop handles file system upgr=
ade (<a href=3D"http://www.storageconference.org/2010/Papers/MSST/Shvachko.=
pdf">http://www.storageconference.org/2010/Papers/MSST/Shvachko.pdf</a>), i=
t is mentioned, &quot;and  block  modifications  during  appends  use  the<=
span class=3D"highlight begin selected"> copy</span><span class=3D"highligh=
t end selected"> on</span> write  technique&quot;,<br>
<ul><li>I think it means old and new file system will keep only one copy us=
ing hard link to save space as long as the file has no change, and if durin=
g upgrade, the file changed (during append operation), then a new updated f=
ile will be created in order to save space. I am not sure if my understandi=
ng is correct?</li>
<li>Another question is, copy-on-write only used to save space for keeping =
snapshot information during file system upgrade? Or it has more broad use c=
ases in HDFS?<br></li></ul><br>regards,<br>Lin<br>

--001517573734c3a59a04d9c50a42--