Never mind I figured it out.<div><br></div><div>First you have to mount -t ldiskfs /dev/OSTDEV /mnt/OST</div><div>Then you can run ll_recover_lost_found_objs.</div><div><br></div><div>Erik<br><br><div class="gmail_quote">On Sat, Jan 2, 2010 at 12:33 PM, Erik Froese <span dir="ltr"><<a href="mailto:erik.froese@gmail.com">erik.froese@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Thanks Andreas,<div><br></div><div>After I e2fsck'd the OST again (and once more to make sure there weren't any errors) the OST mounted cleanly.</div>
<div>I'm not able to run the ll_recover_lost_found_objs.</div>
<div><br></div><div><div>[root@oss-0-0 ~]# ll_recover_lost_found_objs -d /mnt/scratch/ost24/lost+found | tee /tmp/ll_recover_lost_found_obj.ost24</div><div>error: creating objects directory /mnt/scratch/ost24/O: Not a directory</div>

<div>"lost+found" directory path: /mnt/scratch/ost24/lost+found</div><div><br></div><div>The lustre FS is mounted at /scratch on the clients and I don't see a lost+found directory there either.</div><div><br>

</div><div>Erik</div><div><div></div><div class="h5"><br><div class="gmail_quote">On Sat, Jan 2, 2010 at 1:13 AM, Andreas Dilger <span dir="ltr"><<a href="mailto:adilger@sun.com" target="_blank">adilger@sun.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 2010-01-01, at 17:20, Erik Froese wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
On Thu, Dec 31, 2009 at 4:52 PM, Andreas Dilger <<a href="mailto:adilger@sun.com" target="_blank">adilger@sun.com</a>> wrote:<br>
</div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
These are usually a sign that the back-end storage is overloaded, or somehow performing very slowly.  Maybe there was a RAID rebuild going on?<br>
</blockquote>
<br>
I don't see any hw failures or rebuild messages on the RAID. I do see periodic media scans going on.<br>
</div></blockquote>
<br>
There definitely was corruption of the directories on the OST, consistent with what the kernel originally reported, but it looks like it was resolved with a minimum of further problems.  You probably want to run the "ll_recover_lost_found_objs" on this OST to restore the objects from lost+found back to their correct locations, though that isn't strictly necessary to bring the OST back online - it just avoids losing access to the objects that were moved to lost+found due to the directory corruption.<br>


<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div>
Lustre and e2fsprogs versions:<br>
<br>
[root@oss-0-0 ~]# rpm -q kernel-lustre<br>
kernel-lustre-2.6.18-128.7.1.el5_lustre.1.8.1.1<br>
[root@oss-0-0 ~]# rpm -q e2fsprogs<br>
e2fsprogs-1.41.6.sun1-0redhat<br>
<br>
<br>
Then there's this interesting message:<br>
Dec 29 14:11:32 oss-0-0 kernel: LDISKFS-fs error (device sdz): ldiskfs_lookup: unlinked inode 5384166 in dir #145170469<br>
Dec 29 14:11:32 oss-0-0 kernel: Remounting filesystem read-only<br>
<br>
This means the ldiskfs code found some corruption on disk, and remounted<br>
the filesystem read-only to avoid further corruptions on disk.<br>
<br>
<br>
Whenever I try to mount the ost (known as /dev/dsk/ost24) I get the following messages:<br>
Dec 29 19:25:35 oss-0-0 kernel: LDISKFS-fs error (device sdz): ldiskfs_check_descriptors: Checksum for group 16303 failed (64812!=44)<br>
Dec 29 19:25:35 oss-0-0 kernel: LDISKFS-fs: group descriptors corrupted!<br>
<br>
So it looks like the "group descriptors" are corrupted. I'm not sure what those are but e2fsck -n sure enough complains about them. So I tried running it for real.<br>
<br>
I ran e2fsck -j /dev/$JOURNAL -v -fy -C 0 /dev/$DEVICE.<br>
<br>
The first time I ran to what looked like completion. It printed a summary and all but then didn't exit. I sent it a kill but that didn't stop it. So I let it run and went back to sleep for 3 hours. When I woke up the process was gone but I still get the same error messages.<br>


<br>
Having a log of the e2fsck errors would be helpful.<br>
<br>
I don't have the log for the first fsck. First it logged a bunch of messages about the group descriptors and that it was repairing them. Then messages about inodes. I'm attaching the logs from the second e2fsck.<br>


<br>
<br>
<br>
<br>
<br>
I found this discussion <a href="http://lists.lustre.org/pipermail/lustre-discuss/2009-March/009885.html" target="_blank">http://lists.lustre.org/pipermail/lustre-discuss/2009-March/009885.html</a><br>
and tried the tune2fs command followed by the e2fsck but it hasn't exited yet (its a 2.7 TB OST)<br>
<br>
It might take an hour or two, depending on how fast your storage is.<br>
<br>
<br>
The LUN comes from a Sun STK 6140/CSM200 device which isn't reporting any warning, events, or errors.<br>
<br>
I deactivated the OST with lctl but it still shows up as active on the clients. Also lfs find /scratch -O scratch-OST000e_UUID HANGS!<br>
<br>
You also need to deactivate it on the clients, at which point they will<br>
get an IO error when accessing files on that OST.<br>
<br>
 I didn't know that the you had to disable it on the clients as well. Thanks<br>
<br>
<br>
Are we screwed here? Is there a way to run lfs find with the OST disabled? Shouldn't that just be a metadata operation?<br>
<br>
<br>
The size of a file is stored on the OSTs, so it depends on what you are trying to do.  "lfs getstripe" can be run with a deactivated OST.<br>
<br>
<br>
Cheers, Andreas<br>
--<br>
Andreas Dilger<br>
Sr. Staff Engineer, Lustre Group<br>
Sun Microsystems of Canada, Inc.<br>
<br>
<br></div></div>
<e2fsck-fy.sdz.out.post-mmp><br>
</blockquote><div><div></div><div>
<br>
<br>
Cheers, Andreas<br>
--<br>
Andreas Dilger<br>
Sr. Staff Engineer, Lustre Group<br>
Sun Microsystems of Canada, Inc.<br>
<br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>