[
https://issues.apache.org/jira/browse/LUCENE-2373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861356#action_12861356
]
Michael McCandless commented on LUCENE-2373:
--------------------------------------------
{quote}
Mike: I'd hate to add yet another file just for this purpose. Long-term it's
perhaps worth it. Short-term for HDFS use case it would be enough to provide a
method to write a header and a trailer. Codecs that can seek/overwrite would
just use the header, codecs that can't would use both.
{quote}
I think that's a good plan -- abstract the header write/read methods so that
another codec can easily subclass to change how/where these are written. I
think Lucene's default (standard) codec should continue to do what it does now?
And then HDFS can take the standard codec, and subclass
StandardTermsDictWriter/Reader to put the header at the end.
bq. Codecs that operate on filesystems with unreliable fileLength could write
a sync marker before the trailer, and there could be a back-tracking mechanism
that starts from the reported fileLength and then tries to find the sync marker
(reading back, and/or ahead).
Can't we just use the current standard codec's approach by default?
Back-tracking seems dangerous. Eg what if .fileLength() is too small on such
filesystems?
bq. Does this make it possible to add a good checksum?
A codec could easily do this, today -- it's orthogonal to using HDFS. EG
Lucene already has a ChecksumIndexOutput/Input, so this should be a simple
cutover in standard codec (though we would need to fix up the classes, eg to
make "get me the IndexOutput/Input" method, so a subclass could override).
> Change StandardTermsDictWriter to work with streaming and append-only
> filesystems
> ---------------------------------------------------------------------------------
>
> Key: LUCENE-2373
> URL: https://issues.apache.org/jira/browse/LUCENE-2373
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Andrzej Bialecki
> Fix For: 3.1
>
>
> Since early 2.x times Lucene used a skip/seek/write trick to patch the length
> of the terms dict into a place near the start of the output data file. This
> however made it impossible to use Lucene with append-only filesystems such as
> HDFS.
> In the post-flex trunk the following code in StandardTermsDictWriter
> initiates this:
> {code}
> // Count indexed fields up front
> CodecUtil.writeHeader(out, CODEC_NAME, VERSION_CURRENT);
> out.writeLong(0); // leave space for end
> index pointer
> {code}
> and completes this in close():
> {code}
> out.seek(CodecUtil.headerLength(CODEC_NAME));
> out.writeLong(dirStart);
> {code}
> I propose to change this layout so that this pointer is stored simply at the
> end of the file. It's always 8 bytes long, and we known the final length of
> the file from Directory, so it's a single additional seek(length - 8) to read
> it, which is not much considering the benefits.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
