[Lustre-discuss] non-consecutive OST ordering

[Andreas Dilger]

On 2010-11-11, at 19:53, Christopher Walker wrote:
> Thanks very much for your reply. I've tried remaking the mdsdb and all
> of the ostdb's, but I still get the same error -- it checks the first 34
> osts without a problem, but can't find the ostdb file for the 35th
> (which has ost_idx 42):
> 
> with the filesystem up I can see files on this OST:
> 
> [cwalker at iliadaccess04 P-Gadget3.3.1]$ lfs getstripe predict.c
> OBDS:
> 0: aegalfs-OST0000_UUID ACTIVE
> ...
> 33: aegalfs-OST0021_UUID ACTIVE
> 42: aegalfs-OST002a_UUID ACTIVE
> predict.c
> obdidx objid objid group
> 42 10 0xa 0
> 
> 
> lfsck identifies several hundred GB of orphan data that we'd like to
> recover, so we'd really like to run lfsck on this array. We're willing
> to forgo the recovery on the 35th ost, but I want to make sure that
> running lfsck -l with the current configuration won't make things worse.

I'm not sure that what lfsck is reporting in this case is correct.  Is the orphan data all on the same OST, or spread around separate OSTs?  My concern is that if lfsck thinks the in-use objects on your estranged OST is actually orphan data it will destroy that data.

If there are a small number of very large objects on other OSTs that are making up the bulk of the orphan space usage, you could mount those OSTs as type ldiskfs and delete the objects by hand to free up the space.

Cheers, Andreas
--
Andreas Dilger
Lustre Technical Lead
Oracle Corporation Canada Inc.