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 E6B4111B9D for ; Mon, 21 Jul 2014 12:01:39 +0000 (UTC) Received: (qmail 56620 invoked by uid 500); 21 Jul 2014 12:01:31 -0000 Delivered-To: apmail-hadoop-hdfs-user-archive@hadoop.apache.org Received: (qmail 56486 invoked by uid 500); 21 Jul 2014 12:01:31 -0000 Mailing-List: contact user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@hadoop.apache.org Delivered-To: mailing list user@hadoop.apache.org Received: (qmail 56475 invoked by uid 99); 21 Jul 2014 12:01:30 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Jul 2014 12:01:30 +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 (athena.apache.org: domain of dechouxb@gmail.com designates 209.85.215.47 as permitted sender) Received: from [209.85.215.47] (HELO mail-la0-f47.google.com) (209.85.215.47) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Jul 2014 12:01:25 +0000 Received: by mail-la0-f47.google.com with SMTP id mc6so4617954lab.6 for ; Mon, 21 Jul 2014 05:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=nQMnCyEGuL5QcXomGzaMu5vmrLWi8Im+sSppu+pmdFU=; b=YZl3cFdJljIjmwXN9YrocEZcq7KkPrJ/2q8orzfZ869nG7MnSBo/AMy8P8zzmk7cac py+sRDoepFBBP/yckNiHYYeq+LW3ObOKwA4ChGgqtX9lOAhSsPFMxJA8mGXU9JMIg9kD jHxjXEe5yAq5RWzww0HlGXo1Gb2niNY1yDQnyIlKN6nKwA/OUXqP2ywCFfD+n1yMv6tL XbNIIn7m83zVMYBSNcgNhJauM/iCghLpDLNizuiBLxx8cAY/NL9uKuAMNJOiBcMh0Wko A4Khh6Ic6Zn0eV46WQhKUKlfF6cAEjaUGcYi0nQ0KYTFEF/UiTyrcTg22kmQeXTZpDX3 4CmA== MIME-Version: 1.0 X-Received: by 10.112.139.196 with SMTP id ra4mr24428578lbb.28.1405944063456; Mon, 21 Jul 2014 05:01:03 -0700 (PDT) Received: by 10.112.56.233 with HTTP; Mon, 21 Jul 2014 05:01:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Jul 2014 14:01:03 +0200 Message-ID: Subject: Re: Replace a block with a new one From: Bertrand Dechoux To: "user@hadoop.apache.org" Content-Type: multipart/alternative; boundary=001a11c33fcc7a006b04feb2dcef X-Virus-Checked: Checked by ClamAV on apache.org --001a11c33fcc7a006b04feb2dcef Content-Type: text/plain; charset=UTF-8 So you know that a block is corrupted thanks to an external process which in this case is checking the parity blocks. If a block is corrupted but hasn't been detected by HDFS, you could delete the block from the local filesystem (it's only a file) then HDFS will replicate the good remaining replica of this block. For performance reason (and that's what you want to do?), you might be able to fix the corruption without needing to retrieve the good replica. It might be possible by working directly with the local system by replacing the corrupted block by the corrected block (which again are files). On issue is that the corrected block might be different than the good replica. If HDFS is able to tell (with CRC) it might be good else you will end up with two different good replicas for the same block and that will not be pretty... If the result is to be open source, you might want to check with Facebook about their implementation and track the process within Apache JIRA. You could gain additional feedbacks. One downside of HDFS RAID is that the less replicas there is, the less read of the data for processing will be 'efficient/fast'. Reducing the number of replicas also diminishes the number of supported node failures. I wouldn't say it's an easy ride. Bertrand Dechoux On Mon, Jul 21, 2014 at 1:29 PM, Zesheng Wu wrote: > We want to implement a RAID on top of HDFS, something like facebook > implemented as described in: > https://code.facebook.com/posts/536638663113101/saving-capacity-with-hdfs-raid/ > > > 2014-07-21 17:19 GMT+08:00 Bertrand Dechoux : > > You want to implement a RAID on top of HDFS or use HDFS on top of RAID? I >> am not sure I understand any of these use cases. HDFS handles for you >> replication and error detection. Fine tuning the cluster wouldn't be the >> easier solution? >> >> Bertrand Dechoux >> >> >> On Mon, Jul 21, 2014 at 7:25 AM, Zesheng Wu >> wrote: >> >>> Thanks for reply, Arpit. >>> Yes, we need to do this regularly. The original requirement of this is >>> that we want to do RAID(which is based reed-solomon erasure codes) on our >>> HDFS cluster. When a block is corrupted or missing, the downgrade read >>> needs quick recovery of the block. We are considering how to recovery the >>> corrupted/missing block quickly. >>> >>> >>> 2014-07-19 5:18 GMT+08:00 Arpit Agarwal : >>> >>>> IMHO this is a spectacularly bad idea. Is it a one off event? Why not >>>> just take the perf hit and recreate the file? >>>> >>>> If you need to do this regularly you should consider a mutable file >>>> store like HBase. If you start modifying blocks from under HDFS you open up >>>> all sorts of consistency issues. >>>> >>>> >>>> >>>> >>>> On Fri, Jul 18, 2014 at 2:10 PM, Shumin Guo wrote: >>>> >>>>> That will break the consistency of the file system, but it doesn't >>>>> hurt to try. >>>>> On Jul 17, 2014 8:48 PM, "Zesheng Wu" wrote: >>>>> >>>>>> How about write a new block with new checksum file, and replace the >>>>>> old block file and checksum file both? >>>>>> >>>>>> >>>>>> 2014-07-17 19:34 GMT+08:00 Wellington Chevreuil < >>>>>> wellington.chevreuil@gmail.com>: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> there's no way to do that, as HDFS does not provide file updates >>>>>>> features. You'll need to write a new file with the changes. >>>>>>> >>>>>>> Notice that even if you manage to find the physical block replica >>>>>>> files on the disk, corresponding to the part of the file you want to >>>>>>> change, you can't simply update it manually, as this would give a different >>>>>>> checksum, making HDFS mark such blocks as corrupt. >>>>>>> >>>>>>> Regards, >>>>>>> Wellington. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 17 Jul 2014, at 10:50, Zesheng Wu wrote: >>>>>>> >>>>>>> > Hi guys, >>>>>>> > >>>>>>> > I recently encounter a scenario which needs to replace an exist >>>>>>> block with a newly written block >>>>>>> > The most straightforward way to finish may be like this: >>>>>>> > Suppose the original file is A, and we write a new file B which is >>>>>>> composed by the new data blocks, then we merge A and B to C which is the >>>>>>> file we wanted >>>>>>> > The obvious shortcoming of this method is wasting of network >>>>>>> bandwidth >>>>>>> > >>>>>>> > I'm wondering whether there is a way to replace the old block by >>>>>>> the new block directly. >>>>>>> > Any thoughts? >>>>>>> > >>>>>>> > -- >>>>>>> > Best Wishes! >>>>>>> > >>>>>>> > Yours, Zesheng >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best Wishes! >>>>>> >>>>>> Yours, Zesheng >>>>>> >>>>> >>>> >>>> CONFIDENTIALITY NOTICE >>>> NOTICE: This message is intended for the use of the individual or >>>> entity to which it is addressed and may contain information that is >>>> confidential, privileged and exempt from disclosure under applicable law. >>>> If the reader of this message is not the intended recipient, you are hereby >>>> notified that any printing, copying, dissemination, distribution, >>>> disclosure or forwarding of this communication is strictly prohibited. If >>>> you have received this communication in error, please contact the sender >>>> immediately and delete it from your system. Thank You. >>> >>> >>> >>> >>> -- >>> Best Wishes! >>> >>> Yours, Zesheng >>> >> >> > > > -- > Best Wishes! > > Yours, Zesheng > --001a11c33fcc7a006b04feb2dcef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So you know that a block is corrupted thanks to an externa= l process which in this case is checking the parity blocks. If a block is c= orrupted but hasn't been detected by HDFS, you could delete the block f= rom the local filesystem (it's only a file) then HDFS will replicate th= e good remaining replica of this block.

For performance reason (and that's what you want to do?)= , you might be able to fix the corruption without needing to retrieve the g= ood replica. It might be possible by working directly with the local system= by replacing the corrupted block by the corrected block (which again are f= iles). On issue is that the corrected block might be different than the goo= d replica. If HDFS is able to tell (with CRC) it might be good else you wil= l end up with two different good replicas for the same block and that will = not be pretty...

If the result is to be open source, you might want to c= heck with Facebook about their implementation and track the process within = Apache JIRA. You could gain additional feedbacks. One downside of HDFS RAID= is that the less replicas there is, the less read of the data for processi= ng will be 'efficient/fast'. Reducing the number of replicas also d= iminishes the number of supported node failures. I wouldn't say it'= s an easy ride.

Bertrand Dechoux


On Mon, Jul 21, 2014 at 1:29 PM, Zesheng= Wu <wuzesheng86@gmail.com> wrote:
We want to implement a RAID on top of HDFS, something like= facebook implemented as described in:=C2=A0https://code.facebook.com/posts/536638663113101/saving-capacity-with-hd= fs-raid/


2014-07-21 17= :19 GMT+08:00 Bertrand Dechoux <dechouxb@gmail.com>:

You want to implement a RAID on top of HDFS or use HDFS on= top of RAID? I am not sure I understand any of these use cases. HDFS handl= es for you replication and error detection. Fine tuning the cluster wouldn&= #39;t be the easier solution?=C2=A0

Bertrand Dechoux


On Mon, Jul 21, 2014 at 7:25 AM, Zesheng= Wu <wuzesheng86@gmail.com> wrote:
Thanks for reply, Arpit.
Yes, we need to do this regul= arly. The original requirement of this is that we want to do RAID(which is = based reed-solomon erasure codes) on our HDFS cluster. When a block is corr= upted or missing, the downgrade read needs quick recovery of the block. We = are considering how to recovery the corrupted/missing block quickly.


2014-07-19= 5:18 GMT+08:00 Arpit Agarwal <aagarwal@hortonworks.com>:
IMHO this is a spectac= ularly bad idea. Is it a one off event? Why not just take the perf hit and = recreate the file?

If you need to do this regularly you should consider a mutable fi= le store like HBase. If you start modifying blocks from under HDFS you open= up all sorts of consistency issues.




On Fri, Jul 18, 2014 at 2:10 PM, Shumin Guo <gsmste= ve@gmail.com> wrote:

That will break the consisten= cy of the file system, but it doesn't hurt to try.

On Jul 17, 2014 8:48 PM, "Zesheng Wu" = <wuzesheng86@= gmail.com> wrote:
How about write a new block with new checksum file, and re= place the old block file and checksum file both?


2014-07-17 19:34 GMT+08:00 Welling= ton Chevreuil <wellington.chevreuil@gmail.com>:=
Hi,

there's no way to do that, as HDFS does not provide file updates featur= es. You'll need to write a new file with the changes.

Notice that even if you manage to find the physical block replica files on = the disk, corresponding to the part of the file you want to change, you can= 't simply update it manually, as this would give a different checksum, = making HDFS mark such blocks as corrupt.

Regards,
Wellington.



On 17 Jul 2014, at 10:50, Zesheng Wu <wuzesheng86@gmail.com> wrote:

> Hi guys,
>
> I recently encounter a scenario which needs to replace an exist block = with a newly written block
> The most straightforward way to finish may be like this:
> Suppose the original file is A, and we write a new file B which is com= posed by the new data blocks, then we merge A and B to C which is the file = we wanted
> The obvious shortcoming of this method is wasting of network bandwidth=
>
> I'm wondering whether there is a way to replace the old block by t= he new block directly.
> Any thoughts?
>
> --
> Best Wishes!
>
> Yours, Zesheng




--
Best Wishes!

Yours, Zesheng
=

CONFIDENTIA= LITY NOTICE
NOTICE: This message is intended for the use of the individual or e= ntity to which it is addressed and may contain information that is confiden= tial, privileged and exempt from disclosure under applicable law. If the re= ader of this message is not the intended recipient, you are hereby notified= that any printing, copying, dissemination, distribution, disclosure or for= warding of this communication is strictly prohibited. If you have received = this communication in error, please contact the sender immediately and dele= te it from your system. Thank You.



--
Best Wishes!

Yours, Zesheng




--
Best Wishes!

Yours, Zesheng

--001a11c33fcc7a006b04feb2dcef--