Mailing-List: contact hadoop-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hadoop-dev@lucene.apache.org
Message-ID: <6322329.1181182346162.JavaMail.jira@brutus>
Date: Wed, 6 Jun 2007 19:12: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_12502169 ]=20

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

May be two streams for InputChecker is not very generic. May be it could be=
 single stream or not a stream at all but discrete chunks. I have a feeling=
 any generic method will end up requiring extra mem copy of data for atleas=
t some of the implementations of FS.


> 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
>
>
> 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.