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: > > [cwal...@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. _______________________________________________ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
