Mailing-List: contact mapreduce-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mapreduce-issues@hadoop.apache.org
Message-ID: <616270745.456821266912328044.JavaMail.jira@brutus.apache.org>
Date: Tue, 23 Feb 2010 08:05:28 +0000 (UTC)
From: "Rodrigo Schmidt (JIRA)" <jira@apache.org>
To: mapreduce-issues@hadoop.apache.org
Subject: [jira] Updated: (MAPREDUCE-1510) RAID should regenerate parity
 files if they get deleted
In-Reply-To: <938046116.377181266548547899.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/MAPREDUCE-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rodrigo Schmidt updated MAPREDUCE-1510:
---------------------------------------

    Status: Patch Available  (was: Open)

New patch is really simple. The new unit test Dhruba asked for was introduced in  MAPREDUCE-1519. In this patch, I'm just adding test scenarios to cover this specific JIRA.

> RAID should regenerate parity files if they get deleted
> -------------------------------------------------------
>
>                 Key: MAPREDUCE-1510
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-1510
>             Project: Hadoop Map/Reduce
>          Issue Type: Improvement
>          Components: contrib/raid
>            Reporter: Rodrigo Schmidt
>            Assignee: Rodrigo Schmidt
>         Attachments: MAPREDUCE-1510.1.patch, MAPREDUCE-1510.patch
>
>
> Currently, if a source file has a replication factor lower or equal to that expected by RAID, the file is skipped and no parity file is generated. I don't think this is a good behavior since parity files can get wrongly deleted, leaving the source file with a low replication factor. In that case, raid should be able to recreate the parity file.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.