hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Created: (HBASE-509) Our hlog writing 'corrupts' hdfs
Date Thu, 13 Mar 2008 08:17:46 GMT
Our hlog writing 'corrupts' hdfs
--------------------------------

                 Key: HBASE-509
                 URL: https://issues.apache.org/jira/browse/HBASE-509
             Project: Hadoop HBase
          Issue Type: Bug
    Affects Versions: 0.1.0, 0.2.0, 0.16.0
            Reporter: stack
            Priority: Minor


A couple of times during an upload, hdfs complains it is corrupt.  Complaint is as following:

{code}
/hbase/XX.XX.XX-2.u.powerset.com/log_XX.XX.XX.92_1205384328364_60020/hlog.dat.025:  Replica
placement policy is violated for blk_2712323855504360379. Block should be additionally replicated
on 2 more rack(s).
/hbase/XX.XX.XX-2.u.powerset.com/log_XX.XX.XX.92_1205384328364_60020/hlog.dat.025: MISSING
1 blocks of total size 0 B.
{code}

Now the odd thing is that the next time I do a fsck, I see that log number its complaining
about for the above server has increased inline with a new file just rolled as in:

{code}
......92_1205384328364_60020/hlog.dat.026:  Replica placement policy is violated for blk_4062204433046618058.
Block should be additionally replicated on 2 more rack(s).
/hbase/aa0-005-2.u.powerset.com/log_XX.XX.XX.92_1205384328364_60020/hlog.dat.026: MISSING
1 blocks of total size 0 B.
{code}

Its no longer complaining about hlog.dat.025.  If I do an fsck on the file hlog.dat.020, it
says its healthy, replicated 7M file.

Likely an hdfs issue.  Or its the way we're doing our logging? Restart reports cluster HEALTHY
(didn't run fsck with remove 'bad' blocks or files).





-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message