BTW, the new OST sizes will be much different from the original OST sizes. Is the "copy the old file" method below still valid in this case?
bob On 11/7/2010 2:32 PM, Bob Ball wrote: > Hi, Andreas. > > Tomorrow, we will redo all 8 OST on the first file server we are > redoing. I am very nervous about this, as a lot is riding on us doing > this correctly. For example, on a client now, if I umount one of the > ost, without first taking some (unknown to me) action on the MDT, then > the client will hang on the "df" command. > > So, while we are doing the reformat, is there any way to avoid this > "hang" situation? > > Is the --index=XX argument to mkfs.lustre hex, or decimal? Seems from > your comment below that this must be hex? > > Finally, does supplying the --index even matter if we restore the files > below that you mention? That seems to be what you are saying. > > Thanks much, > bob > > On 11/6/2010 11:09 AM, Andreas Dilger wrote: >> On 2010-11-06, at 8:24, Bob Ball<[email protected]> wrote: >>> I am emptying a set of OST so that I can reformat the underlying RAID-6 >>> more efficiently. Two questions: >>> 1. Is there a quick way to tell if the OST is really empty? lfs_find >>> takes many hours to run. >> If you mount the OST as type ldiskfs and look in the O/0/d* directories >> (capital-O, zero) there should be a few hundred zero-length objects owned by >> root. >> >>> 2. When I reformat, I want it to retain the same ID so as to not make >>> "holes" in the list. From the following information, am I correct to >>> assume that the id is 24? If not, how do I determine the correct ID to >>> use when we re-create the file system? >> If you still have the existing OST, the easiest way to do this is to save >> the files last_rcvd, O/0/LAST_ID, and CONFIGS/*, and copy them into the >> reformatted OST. >> >>> /dev/sdj 3.5T 3.1T 222G 94% /mnt/ost51 >>> 10 UP obdfilter umt3-OST0018 umt3-OST0018_UUID 547 >>> umt3-OST0018_UUID 3.4T 3.0T 221.1G 88% >>> /lustre/umt3[OST:24] >>> 20 IN osc umt3-OST0018-osc umt3-mdtlov_UUID 5 >> The OST index is indeed 24 (18 hex). As for /dev/sdj, it is hard to know >> from the above info. If you run "e2label /dev/sdj" the filesystem label >> should match the OST name umt3-OST0018. >> >> Cheers, Andreas >> > _______________________________________________ > Lustre-discuss mailing list > [email protected] > http://lists.lustre.org/mailman/listinfo/lustre-discuss > > _______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
