Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hadoop-dev@lucene.apache.org
Message-ID: <19279981.1181250566226.JavaMail.jira@brutus>
Date: Thu, 7 Jun 2007 14:09:26 -0700 (PDT)
From: "Raghu Angadi (JIRA)" <jira@apache.org>
To: hadoop-dev@lucene.apache.org
Subject: [jira] Commented: (HADOOP-1470) Rework FSInputChecker and
 FSOutputSummer to support checksum code sharing between ChecksumFileSystem
 and block level crc dfs
In-Reply-To: <7723731.1181157326809.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HADOOP-1470?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502511 ]=20

Raghu Angadi commented on HADOOP-1470:
--------------------------------------

> could you use the above?=20
_can_ I? Yeah sure, my argument has never been it _can not_  be done. We ca=
n even rechecksum to hide mismatch between {{bpc}} and {{blockSize}}.

Though I don't agree with 'it is good enough until it is extremely difficul=
t to use', whether it is implied here or not. I surely don't think it is an=
 improvement over FSInputChecker which, I think, was not explicitly designe=
d to be general purpose checker.=20
=20
I sure hope this is not a blocker for HADOOP-1134.

> Rework FSInputChecker and FSOutputSummer to support checksum code sharing=
 between ChecksumFileSystem and block level crc dfs
> -------------------------------------------------------------------------=
---------------------------------------------------
>
>                 Key: HADOOP-1470
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1470
>             Project: Hadoop
>          Issue Type: Improvement
>          Components: fs
>    Affects Versions: 0.12.3
>            Reporter: Hairong Kuang
>            Assignee: Hairong Kuang
>             Fix For: 0.14.0
>
>         Attachments: genericChecksum.patch
>
>
> Comment from Doug in HADOOP-1134:
> I'd prefer it if the CRC code could be shared with CheckSumFileSystem. In=
 particular, it seems to me that FSInputChecker and FSOutputSummer could be=
 extended to support pluggable sources and sinks for checksums, respectivel=
y, and DFSDataInputStream and DFSDataOutputStream could use these. Advantag=
es of this are: (a) single implementation of checksum logic to debug and ma=
intain; (b) keeps checksumming as close to possible to data generation and =
use. This patch computes checksums after data has been buffered, and valida=
tes them before it is buffered. We sometimes use large buffers and would li=
ke to guard against in-memory errors. The current checksum code catches a l=
ot of such errors. So we should compute checksums after minimal buffering (=
just bytesPerChecksum, ideally) and validate them at the last possible mome=
nt (e.g., through the use of a small final buffer with a larger buffer behi=
nd it). I do not think this will significantly affect performance, and data=
 integrity is a high priority.=20

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