<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi bob,<br>
      <br>
      just to make sure: You already followed:
      <a class="moz-txt-link-freetext" href="http://wiki.lustre.org/index.php/Handling_File_System_Errors">http://wiki.lustre.org/index.php/Handling_File_System_Errors</a>,
      especially the steps for e2fsck linked there?<br>
      <br>
      If you did *not yet* do any write operation to the damaged OST,
      you might want to back up the whole OST first, using dd for
      instance (if the underlying hardware still permits it).<br>
      <br>
      If the situation described (empty O directory, lost LAST_ID entry)
      occurred *after* the e2fsck, and you find lots of files in
      lost+found when you mount the OST as ldiskfs, you can use
      ll_recover_lost_found_objs to put them back in the correct place
      (<a class="moz-txt-link-freetext" href="http://manpages.ubuntu.com/manpages/precise/man1/ll_recover_lost_found_objs.1.html">http://manpages.ubuntu.com/manpages/precise/man1/ll_recover_lost_found_objs.1.html</a>)
      - it is part of the lustre distribution. Once I had to run this
      several times in order to restore the structure below. <br>
      <br>
      best regards,<br>
      Martin<br>
      <br>
      On 05/19/2014 08:24 PM, Bob Ball wrote:<br>
    </div>
    <blockquote cite="mid:537A4C56.8040606@umich.edu" type="cite">Oh,
      better still, as I kept looking, and the low-level panic
      retreated, I found this on the mdt:
      <br>
      <br>
      [root@lmd02 ~]# lctl get_param osc.*.prealloc_next_id
      <br>
      ...
      <br>
      osc.umt3-OST0025-osc.prealloc_next_id=6778336
      <br>
      <br>
      So, unless someone tells me that I am way off base, I'm going to
      proceed with the assumption that this is a valid starting point,
      and proceed to get my file system back online.
      <br>
      <br>
      bob
      <br>
      <br>
      On 5/19/2014 2:05 PM, Bob Ball wrote:
      <br>
      <blockquote type="cite">Google first, ask later.  I found this in
        the manuals:
        <br>
        <br>
        <br>
              26.3.4 Fixing a Bad LAST_ID on an OST
        <br>
        <br>
        The procedures there spell out pretty well what I must do, so
        this should be relatively straight forward.  But, does this
        comment refer to just this OST, or to all OST?
        <br>
        *Note - *The file system must be stopped on all servers before
        performing this procedure.
        <br>
        <br>
        So, is this the best approach to follow, allowing for the fact
        that there is nothing at all left on the OST, or is there a
        better short cut to choosing an appropriate LAST_ID?
        <br>
        <br>
        Thanks again,
        <br>
        bob
        <br>
        <br>
        <br>
        On 5/19/2014 1:50 PM, Bob Ball wrote:
        <br>
        <blockquote type="cite">I need to completely remake a failed
          OST.  I have done this in the past, but this time, the disk
          failed in such a way that I cannot fully get recovery
          information from the OST before I destroy and recreate.  In
          particular, I am unable to recover the LAST_ID file, but
          successfully retrieved the last_rcvd and CONFIGS/* files.
          <br>
          <br>
          mount -t ldiskfs /dev/sde /mnt/ost
          <br>
          pushd /mnt/ost
          <br>
          cd O
          <br>
          cd 0
          <br>
          cp -p LAST_ID /root/reformat/sde
          <br>
          <br>
          The O directory exists, but it is empty.  What can I do
          concerning this missing LAST_ID file?  I mean, I probably have
          something, somewhere, from some previous recovery, but that is
          way, way out of date.
          <br>
          <br>
          My intent is to recreate this OST with the same index, and
          then put it back into production.  All files were moved off
          the OST before reaching this state, so nothing else needs to
          be recovered here.
          <br>
          <br>
          Thanks,
          <br>
          bob
          <br>
          <br>
          _______________________________________________
          <br>
          HPDD-discuss mailing list
          <br>
          <a class="moz-txt-link-abbreviated" href="mailto:HPDD-discuss@lists.01.org">HPDD-discuss@lists.01.org</a>
          <br>
          <a class="moz-txt-link-freetext" href="https://lists.01.org/mailman/listinfo/hpdd-discuss">https://lists.01.org/mailman/listinfo/hpdd-discuss</a>
          <br>
          <br>
        </blockquote>
        <br>
        <br>
        <br>
        _______________________________________________
        <br>
        HPDD-discuss mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:HPDD-discuss@lists.01.org">HPDD-discuss@lists.01.org</a>
        <br>
        <a class="moz-txt-link-freetext" href="https://lists.01.org/mailman/listinfo/hpdd-discuss">https://lists.01.org/mailman/listinfo/hpdd-discuss</a>
        <br>
      </blockquote>
      <br>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
HPDD-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:HPDD-discuss@lists.01.org">HPDD-discuss@lists.01.org</a>
<a class="moz-txt-link-freetext" href="https://lists.01.org/mailman/listinfo/hpdd-discuss">https://lists.01.org/mailman/listinfo/hpdd-discuss</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>