HBase
  1. HBase
  2. HBASE-7108

Don't use legal family name for system folder at region level

    Details

    • Type: Bug Bug
    • Status: Patch Available
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.92.2, 0.94.2, 0.95.2
    • Fix Version/s: 0.99.0
    • Component/s: regionserver
    • Labels:
      None

      Description

      CHANGED, was: Don't allow "recovered.edits" as legal family name

      Region directories can contain folders called "recovered.edits", log splitting related.
      But there's nothing that prevent a user to create a family with that name...

      HLog.RECOVERED_EDITS_DIR = "recovered.edits";
      HRegion.MERGEDIR = "merges"; // fixed with HBASE-6158
      SplitTransaction.SPLITDIR = "splits"; // fixed with HBASE-6158

      1. HBASE-7108-v0.patch
        2 kB
        Matteo Bertozzi

        Issue Links

          Activity

          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12552359/HBASE-7108-v0.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          -1 tests included. The patch doesn't appear to include any new or modified tests.
          Please justify why no new tests are needed for this patch.
          Also please list what manual steps were performed to verify this patch.

          -1 patch. The patch command could not apply the patch.

          Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/8180//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12552359/HBASE-7108-v0.patch against trunk revision . +1 @author . The patch does not contain any @author tags. -1 tests included . The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. -1 patch . The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/8180//console This message is automatically generated.
          Hide
          stack added a comment -

          You up for making the suggested change Matteo Bertozzi? Would be good one to get into 0.96. Good on you.

          Show
          stack added a comment - You up for making the suggested change Matteo Bertozzi ? Would be good one to get into 0.96. Good on you.
          Hide
          stack added a comment -

          Todd's suggestion sounds good to me.

          Show
          stack added a comment - Todd's suggestion sounds good to me.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12552359/HBASE-7108-v0.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          -1 tests included. The patch doesn't appear to include any new or modified tests.
          Please justify why no new tests are needed for this patch.
          Also please list what manual steps were performed to verify this patch.

          +1 hadoop2.0. The patch compiles against the hadoop 2.0 profile.

          -1 javadoc. The javadoc tool appears to have generated 87 warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          -1 findbugs. The patch appears to introduce 15 new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed these unit tests:
          org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat

          Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
          Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12552359/HBASE-7108-v0.patch against trunk revision . +1 @author . The patch does not contain any @author tags. -1 tests included . The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 hadoop2.0 . The patch compiles against the hadoop 2.0 profile. -1 javadoc . The javadoc tool appears to have generated 87 warning messages. +1 javac . The applied patch does not increase the total number of javac compiler warnings. -1 findbugs . The patch appears to introduce 15 new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. -1 core tests . The patch failed these unit tests: org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/3239//console This message is automatically generated.
          Hide
          Todd Lipcon added a comment -

          For compatibility, one option would be:

          • in 0.94: change code to recognize both "recovered.edits" and ".recovered.edits" at region-open time
          • in 0.96: change code to write to ".recovered.edits" and recognize both

          Then, so long as someone is upgrading from the most recent 0.94 to 0.96, they'd be fine. An upgrade from an older 0.94 or 0.92 to 0.96 would potentially have an issue if there were a failure in the middle of a rolling upgrade.

          Would that be acceptible?

          Show
          Todd Lipcon added a comment - For compatibility, one option would be: in 0.94: change code to recognize both "recovered.edits" and ".recovered.edits" at region-open time in 0.96: change code to write to ".recovered.edits" and recognize both Then, so long as someone is upgrading from the most recent 0.94 to 0.96, they'd be fine. An upgrade from an older 0.94 or 0.92 to 0.96 would potentially have an issue if there were a failure in the middle of a rolling upgrade. Would that be acceptible?
          Hide
          Matteo Bertozzi added a comment -

          yeah good catch, we don't allow the '.' as starting character in the family name.
          So, can I just rename "recovered.edits" in ".recovered.edits"?
          do we preserve fs layout compatibility in some way?

          Show
          Matteo Bertozzi added a comment - yeah good catch, we don't allow the '.' as starting character in the family name. So, can I just rename "recovered.edits" in ".recovered.edits"? do we preserve fs layout compatibility in some way?
          Hide
          Todd Lipcon added a comment -

          Instead of disallowing it, could we change recovered.edits to be something starting with a '.'? I think we already have some requirement that CFs not start with '.', right? (if not, is there any other prefix which we've already disallowed for users?)

          Show
          Todd Lipcon added a comment - Instead of disallowing it, could we change recovered.edits to be something starting with a '.'? I think we already have some requirement that CFs not start with '.', right? (if not, is there any other prefix which we've already disallowed for users?)
          Hide
          Matteo Bertozzi added a comment -

          added patch to mark "recovered.edits" as Illegal family name

          Show
          Matteo Bertozzi added a comment - added patch to mark "recovered.edits" as Illegal family name

            People

            • Assignee:
              Matteo Bertozzi
              Reporter:
              Matteo Bertozzi
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:

                Development