<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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>
    <div class="moz-cite-prefix">On 5/19/2014 2:05 PM, Bob Ball wrote:<br>
    </div>
    <blockquote cite="mid:537A47F6.3010103@umich.edu" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      Google first, ask later.  I found this in the manuals:<br>
      <h3 class="Head2">26.3.4 <a moz-do-not-send="true"
          name="50438198_69657"></a>Fixing a Bad LAST_ID on an OST</h3>
      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>
      <b class="TipNote">Note - </b><a moz-do-not-send="true"
        name="50438198_pgfId-1296798"></a>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>
      <div class="moz-cite-prefix">On 5/19/2014 1:50 PM, Bob Ball wrote:<br>
      </div>
      <blockquote cite="mid:537A447F.5000006@umich.edu" 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 moz-do-not-send="true" class="moz-txt-link-abbreviated"
          href="mailto:HPDD-discuss@lists.01.org">HPDD-discuss@lists.01.org</a>
        <br>
        <a moz-do-not-send="true" 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>
      <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>