xfs_repair fails to complete with error “Aborted (core dumped)”





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







0















I have a RHEL version 6 machine (appliance) configured with a RAID 6 array containing 12 disks, configured for DRBD with an identical appliance in the same physical chassis. This array is partitioned into 9 drives, one of which contains the boot sector; there is no separate local boot disk. The device has a hardware RAID controller; I'm unsure the specific model.



We attempted to hot-swap a disk, and the system went into what I can only assume was a kernel panic. This forced us to restart the machine at bare metal. After quite a bit of tinkering (extensive, but irrelevant to the question), we're able to mount the boot partition, log partition, recovery partition, etc; and all of these work fine.



However, the largest partition, the "/store" partition which contains the data we're trying to gain access to, is still partially corrupted. The disk will mount after an xfs_repair -L, however we can't get to a significant amount of the data, nor can we bring up the appliance due to PGSQL having a number of corrupted directories.



When running xfs_repair, it runs for approximately 1 hour; the most common notifications written to the screen are below, in order from most common to least common. Please note that there are enough of these the speed of scrolling is reminiscent of a script running an infinite loop; I am unable to count how many of each. Additionally, I'm quite sure I've missed some somewhere.



Phase 2:



block (##############) multiply claimed by bno space tree, state - 1
block (##############) multiply claimed by bno space tree, state - 2
block (##############) multiply claimed by cnt space tree, state - 2
block (##############) multiply claimed by cnt space tree, state - 1
inode chunk claims used block, inobt block - agno 24, bno #####, inopb 16


Phase 3:



found inodes not in the inode allocation tree
bad inode format in inode ################
bad magic number #x#### in inode #########, resetting magic number
bad (negative) size -##################### on inode #############


Somewhere in here, it throws the following, and then exits:



xfs_repair: dinode.c:768: process_bmbt_reclist_int: Assertion `i < *numrecs' failed.
Aborted (core dumped)


Does anyone have any idea how I can get the xfs_repair to progress past this point?










share|improve this question





























    0















    I have a RHEL version 6 machine (appliance) configured with a RAID 6 array containing 12 disks, configured for DRBD with an identical appliance in the same physical chassis. This array is partitioned into 9 drives, one of which contains the boot sector; there is no separate local boot disk. The device has a hardware RAID controller; I'm unsure the specific model.



    We attempted to hot-swap a disk, and the system went into what I can only assume was a kernel panic. This forced us to restart the machine at bare metal. After quite a bit of tinkering (extensive, but irrelevant to the question), we're able to mount the boot partition, log partition, recovery partition, etc; and all of these work fine.



    However, the largest partition, the "/store" partition which contains the data we're trying to gain access to, is still partially corrupted. The disk will mount after an xfs_repair -L, however we can't get to a significant amount of the data, nor can we bring up the appliance due to PGSQL having a number of corrupted directories.



    When running xfs_repair, it runs for approximately 1 hour; the most common notifications written to the screen are below, in order from most common to least common. Please note that there are enough of these the speed of scrolling is reminiscent of a script running an infinite loop; I am unable to count how many of each. Additionally, I'm quite sure I've missed some somewhere.



    Phase 2:



    block (##############) multiply claimed by bno space tree, state - 1
    block (##############) multiply claimed by bno space tree, state - 2
    block (##############) multiply claimed by cnt space tree, state - 2
    block (##############) multiply claimed by cnt space tree, state - 1
    inode chunk claims used block, inobt block - agno 24, bno #####, inopb 16


    Phase 3:



    found inodes not in the inode allocation tree
    bad inode format in inode ################
    bad magic number #x#### in inode #########, resetting magic number
    bad (negative) size -##################### on inode #############


    Somewhere in here, it throws the following, and then exits:



    xfs_repair: dinode.c:768: process_bmbt_reclist_int: Assertion `i < *numrecs' failed.
    Aborted (core dumped)


    Does anyone have any idea how I can get the xfs_repair to progress past this point?










    share|improve this question

























      0












      0








      0








      I have a RHEL version 6 machine (appliance) configured with a RAID 6 array containing 12 disks, configured for DRBD with an identical appliance in the same physical chassis. This array is partitioned into 9 drives, one of which contains the boot sector; there is no separate local boot disk. The device has a hardware RAID controller; I'm unsure the specific model.



      We attempted to hot-swap a disk, and the system went into what I can only assume was a kernel panic. This forced us to restart the machine at bare metal. After quite a bit of tinkering (extensive, but irrelevant to the question), we're able to mount the boot partition, log partition, recovery partition, etc; and all of these work fine.



      However, the largest partition, the "/store" partition which contains the data we're trying to gain access to, is still partially corrupted. The disk will mount after an xfs_repair -L, however we can't get to a significant amount of the data, nor can we bring up the appliance due to PGSQL having a number of corrupted directories.



      When running xfs_repair, it runs for approximately 1 hour; the most common notifications written to the screen are below, in order from most common to least common. Please note that there are enough of these the speed of scrolling is reminiscent of a script running an infinite loop; I am unable to count how many of each. Additionally, I'm quite sure I've missed some somewhere.



      Phase 2:



      block (##############) multiply claimed by bno space tree, state - 1
      block (##############) multiply claimed by bno space tree, state - 2
      block (##############) multiply claimed by cnt space tree, state - 2
      block (##############) multiply claimed by cnt space tree, state - 1
      inode chunk claims used block, inobt block - agno 24, bno #####, inopb 16


      Phase 3:



      found inodes not in the inode allocation tree
      bad inode format in inode ################
      bad magic number #x#### in inode #########, resetting magic number
      bad (negative) size -##################### on inode #############


      Somewhere in here, it throws the following, and then exits:



      xfs_repair: dinode.c:768: process_bmbt_reclist_int: Assertion `i < *numrecs' failed.
      Aborted (core dumped)


      Does anyone have any idea how I can get the xfs_repair to progress past this point?










      share|improve this question














      I have a RHEL version 6 machine (appliance) configured with a RAID 6 array containing 12 disks, configured for DRBD with an identical appliance in the same physical chassis. This array is partitioned into 9 drives, one of which contains the boot sector; there is no separate local boot disk. The device has a hardware RAID controller; I'm unsure the specific model.



      We attempted to hot-swap a disk, and the system went into what I can only assume was a kernel panic. This forced us to restart the machine at bare metal. After quite a bit of tinkering (extensive, but irrelevant to the question), we're able to mount the boot partition, log partition, recovery partition, etc; and all of these work fine.



      However, the largest partition, the "/store" partition which contains the data we're trying to gain access to, is still partially corrupted. The disk will mount after an xfs_repair -L, however we can't get to a significant amount of the data, nor can we bring up the appliance due to PGSQL having a number of corrupted directories.



      When running xfs_repair, it runs for approximately 1 hour; the most common notifications written to the screen are below, in order from most common to least common. Please note that there are enough of these the speed of scrolling is reminiscent of a script running an infinite loop; I am unable to count how many of each. Additionally, I'm quite sure I've missed some somewhere.



      Phase 2:



      block (##############) multiply claimed by bno space tree, state - 1
      block (##############) multiply claimed by bno space tree, state - 2
      block (##############) multiply claimed by cnt space tree, state - 2
      block (##############) multiply claimed by cnt space tree, state - 1
      inode chunk claims used block, inobt block - agno 24, bno #####, inopb 16


      Phase 3:



      found inodes not in the inode allocation tree
      bad inode format in inode ################
      bad magic number #x#### in inode #########, resetting magic number
      bad (negative) size -##################### on inode #############


      Somewhere in here, it throws the following, and then exits:



      xfs_repair: dinode.c:768: process_bmbt_reclist_int: Assertion `i < *numrecs' failed.
      Aborted (core dumped)


      Does anyone have any idea how I can get the xfs_repair to progress past this point?







      linux raid mount xfs






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Feb 6 at 19:04









      HaybuckHaybuck

      11




      11






















          0






          active

          oldest

          votes












          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "3"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1402816%2fxfs-repair-fails-to-complete-with-error-aborted-core-dumped%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          0






          active

          oldest

          votes








          0






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes
















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Super User!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1402816%2fxfs-repair-fails-to-complete-with-error-aborted-core-dumped%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Plaza Victoria

          In PowerPoint, is there a keyboard shortcut for bulleted / numbered list?

          How to put 3 figures in Latex with 2 figures side by side and 1 below these side by side images but in...