[ http://issues.apache.org/jira/browse/HADOOP-54?page=comments#action_12422719 ] eric baldeschwieler commented on HADOOP-54: -------------------------------------------
Arun, what does flush do exactly? Does it create a block boundary? I'd vote for not expanding the interface until we have a compelling use case. Although I can see how this could arise. PS. I'm all for hardcoding a value of 2MB or something else sane for the block size. Keeping things simple is often much more important than making everything configurable. As long as the API lets you set the buffer size on creation, I'm happy. My experience with such systems is at some point the number of configuration options becomes a weakness, not a strength. Happy to be out voted on this point. (In this case) > SequenceFile should compress blocks, not individual entries > ----------------------------------------------------------- > > Key: HADOOP-54 > URL: http://issues.apache.org/jira/browse/HADOOP-54 > Project: Hadoop > Issue Type: Improvement > Components: io > Affects Versions: 0.2.0 > Reporter: Doug Cutting > Assigned To: Arun C Murthy > Fix For: 0.5.0 > > Attachments: VIntCompressionResults.txt > > > SequenceFile will optionally compress individual values. But both > compression and performance would be much better if sequences of keys and > values are compressed together. Sync marks should only be placed between > blocks. This will require some changes to MapFile too, so that all file > positions stored there are the positions of blocks, not entries within > blocks. Probably this can be accomplished by adding a > getBlockStartPosition() method to SequenceFile.Writer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
