<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.&nbsp; I found this in
        the manuals:
        <br>
        <br>
        <br>
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; What can I do
          concerning this missing LAST_ID file?&nbsp; 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.&nbsp; 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>