<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
OK, this worked. I was able to rewrite the LAST_ID value stored in the
lov_objid object to a value of 1, and when lustre came up, the ost was
back at "UP" (yay!).<br>
<br>
However, there still seem to be problems with that ost, as lfs_find
comes up with files there that do not exist. I guess at some point
we'll have to take a complete outage to fix the file system
consistency. But in the meantime thank you all for your help and
advice.<br>
<br>
I must say though, I like this 1.8.4 version much better than 1.8.3.
We were even able to migrate live between versions to do the upgrade,
so no down-time was involved.<br>
<br>
bob<br>
<br>
Bob Ball wrote:
<blockquote cite="mid:4C8A4C0C.30800@umich.edu" type="cite">
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
I just made some random checks on the "lfs find" output for this OST
from yesterday. Each file I checked was one lost when we had problems
a few months back. The suggested "unlink" on these did not work in
1.8.3, worked fine on a whole set yesterday with 1.8.4, but I obviously
did not find them all.<br>
<br>
So, I am going to assume that this OST is completely empty. I will
make a backup of the lov_objid file, then see if I can do a binary edit
using xxd, hopefully avoiding the kernel panic. Crossing my fingers.
Will announce a short outage here to begin in 45 minutes from now.<br>
<br>
bob<br>
<br>
Bernd Schubert wrote:
<blockquote cite="mid:4C8A473A.1030909@ddn.com" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Assuming the disk really is empty then, and LAST_ID really is zero,
shall I then leave it at zero, and follow the recommendation of
page 23-14, ie, just shut down again, delete the lov_objid file on
the MDS, and restart the system? Certainly the value at the
correct index (29) is definitely hosed: # od -Ax -td8
/mnt/mdt/lov_objid (snip) 0000d0 292648
346413 0000e0 68225 -7137254917378053186 0000f0
59064 59607 000100 59227
59414
</pre>
</blockquote>
<pre wrap="">Yes, that is definitely hosed. Deleting the lov_objid file from the
MDS and remounting the MDS should fix this value. You could also
just binary edit the file and set this to 1.
</pre>
</blockquote>
<pre wrap=""><!---->
Andreas, Bob, please be very very careful with lov_objid. As I already
wrote last week, I get reproducibly and always a hard kernel panic when
I tested and deleted the file and then mounted the MDT again.
You can try it, but DO CREATE A BACKUP of this file, so that you can
copy it back, if something goes wrong.
Sorry, I don't have the time right now to work on the
lob_objid-delete-bug, not even time to write a suitable bug report :(
Cheers,
Bernd
</pre>
</blockquote>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Lustre-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Lustre-discuss@lists.lustre.org">Lustre-discuss@lists.lustre.org</a>
<a class="moz-txt-link-freetext" href="http://lists.lustre.org/mailman/listinfo/lustre-discuss">http://lists.lustre.org/mailman/listinfo/lustre-discuss</a>
</pre>
</blockquote>
</body>
</html>