[
https://issues.apache.org/jira/browse/HBASE-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566781#action_12566781
]
Bryan Duxbury commented on HBASE-2:
-----------------------------------
No question that a long is "overkill" for representing the number of .dat files
we'll have. However, we selected System.currentTimeMillis() because it would
give us a unique, increasing number every time. Storing an additional 7-10
bytes per filename seems like a reasonable tradeoff.
As far as the question of zero-fill, it's actually pretty moot, because it will
only matter when the length of the timestamps increases by a full order of
magnitude. For today, that means going from around 1.2 billion seconds since
epoch to 10 billion seconds since epoch, which is about 300 years from now.
Even then, the problem would only manifest if two log files were created across
the 10 billion rollover. Do you think that we can be ok with a 1-second danger
zone 300 years from now?
> hlog numbers should wrap around when they reach 999
> ---------------------------------------------------
>
> Key: HBASE-2
> URL: https://issues.apache.org/jira/browse/HBASE-2
> Project: Hadoop HBase
> Issue Type: Bug
> Components: regionserver
> Reporter: Billy Pearson
> Assignee: Bryan Duxbury
> Priority: Minor
> Fix For: 0.2.0
>
> Attachments: 2-v2.patch, 2.patch
>
>
> Question about log numbers -> Closing current log writer
> hdfs://10.0.0.1:9000/gfs_storage/hadoop-root/hbase/log_10.0.0.3_1201900440436_60020/hlog.dat.024
> What happens when the log get to hlog.dat.999
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
