You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Commit Tag Bot (JIRA)" <ji...@apache.org> on 2013/03/22 17:29:23 UTC
[jira] [Commented] (LUCENE-4455) CheckIndex shows wrong segment
size in 4.0 because SegmentInfoPerCommit.sizeInBytes counts every file 2
times; check for deletions is negated and results in wrong output
[ https://issues.apache.org/jira/browse/LUCENE-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13610715#comment-13610715 ]
Commit Tag Bot commented on LUCENE-4455:
----------------------------------------
[branch_4x commit] Michael McCandless
http://svn.apache.org/viewvc?view=revision&revision=1392482
LUCENE-4455: fix SIPC.sizeInBytes() to not double-count; fix CheckIndex to not reverse 'has deletions'/'no deletions'
> CheckIndex shows wrong segment size in 4.0 because SegmentInfoPerCommit.sizeInBytes counts every file 2 times; check for deletions is negated and results in wrong output
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-4455
> URL: https://issues.apache.org/jira/browse/LUCENE-4455
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
> Affects Versions: 4.0-BETA
> Reporter: Uwe Schindler
> Assignee: Michael McCandless
> Priority: Blocker
> Fix For: 4.0, 5.0
>
> Attachments: LUCENE-4455.patch
>
>
> I found this bug in 4.0-RC1 when I compared the checkindex outputs for 4.0 and 3.6.1:
> - The segment size is twice as big as reported by "ls -lh". The reason is that SegmentInfoPerCommit.sizeInBytes counts every file 2 times. This seems to be not so serious (it is just statistics), *but*: MergePolicy chooses merges because of this. On the other hand if all segments are twice as big it should not affect merging behaviour (unless absolute sizes in megabytes are used). So we should really fix this - sorry for investigating this so late!
> - The deletions in the segments are inverted. Segments that have no deleteions are reported as those *with deletions* but delGen=-1, and those with deletions show "no deletions", this is not serious, but should be fixed, too.
> There is one "bug" in sizeInBytes (which we should NOT fix), is that for 3.x indexes, if they are from 3.0 and have shared doc stores they are overestimated. But that's fine. For this case, the index was a 3.6.1 segment and a 4.0 segment, both showed double size.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org