[Lustre-discuss] Solved: incorrect num_osts; LBUG

Andreas Dilger adilger at sun.com
Tue Jan 6 01:39:23 PST 2009

On Jan 04, 2009  14:25 -0600, Michael Sternberg wrote:
> On Jan 2, 2009, at 19:24 , Michael Sternberg wrote:
> > While performing an LFSCK after upgrade lustre-1.6.6, the MDS claims
> > to have 512 OSTs [while there is only 1]:
> >
> > 	MDS: num_osts = 512
> Well, I found an interesting section "How to fix bad LAST_ID on an  
> OST" in the operations manual, Appendix D, which pointed more or less  
> in the right direction.
> Briefly, /lov_objid within the MDS ldiskfs is constructed from /O/0/ 
> LAST_ID in all the OSTs' ldiskfs.  In my case, with only one OST, the  
> first and only entry agrees between these two files, and the rest of  
> lov_objid was padded with NULs to 4KB (block size?).  I do not  
> understand what caused this, but, given prior e2fsck output indicating  
> length 8, I decided to simply chop off the NULs, which indeed made  
> e2fsck happy.  lfsck on a client found a handful of empty orphans, but  
> a backup on the client side still matches the contents of the rest of  
> the fs (phew!).

As a further note - lfsck is not really a required operation.  Lustre
will normally handle the problems that lfsck would fix, with the
exception of corruption that results in two inodes referencing the same
object (which can also be fixed by hand if necessary).

Cheers, Andreas
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

More information about the lustre-discuss mailing list