<html><body bgcolor="#FFFFFF"><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">On 2010-11-07, at 12:32, Bob Ball <<a href="mailto:ball@umich.edu">ball@umich.edu</a>> wrote:</span></div><blockquote type="cite"><div><span>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.</span><br><span></span><br><span>So, while we are doing the reformat, is there any way to avoid this "hang" situation?</span><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#0023A3"><br></font></font></div></blockquote><div><br></div>If you issue "lctl --device %{OSC UUID} deactivate" on the MDS and clients then any operations on those OSTs will immediately fail with an IO error. If you are migrating I objects from those OSTs, I would have imagined you already did this on the MDS or new objects would have continued to be allocated there<div><br><blockquote type="cite"><div><span>Is the --index=XX argument to mkfs.lustre hex, or decimal? Seems from your comment below that this must be hex?</span><br></div></blockquote><div><br></div>Decimal, though it may also accept hex (I can't check right now). </div><div><br><blockquote type="cite"><div><span>Finally, does supplying the --index even matter if we restore the files below that you mention? That seems to be what you are saying.</span><br></div></blockquote><div><br></div>Well, you still need to set the filesystem label. This could be done with tune2fs, but you may as well specify the right index from the beginning. </div><div> <br><blockquote type="cite"><div><span>On 11/6/2010 11:09 AM, Andreas Dilger wrote:</span><br><blockquote type="cite"><span>On 2010-11-06, at 8:24, Bob Ball<<a href="mailto:ball@umich.edu">ball@umich.edu</a>> wrote:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>I am emptying a set of OST so that I can reformat the underlying RAID-6</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>more efficiently. Two questions:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>1. Is there a quick way to tell if the OST is really empty? lfs_find</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>takes many hours to run.</span><br></blockquote></blockquote><blockquote type="cite"><span>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.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>2. When I reformat, I want it to retain the same ID so as to not make</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>"holes" in the list. From the following information, am I correct to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>assume that the id is 24? If not, how do I determine the correct ID to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>use when we re-create the file system?</span><br></blockquote></blockquote><blockquote type="cite"><span>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.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>/dev/sdj 3.5T 3.1T 222G 94% /mnt/ost51</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> 10 UP obdfilter umt3-OST0018 umt3-OST0018_UUID 547</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>umt3-OST0018_UUID 3.4T 3.0T 221.1G 88%</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>/lustre/umt3[OST:24]</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> 20 IN osc umt3-OST0018-osc umt3-mdtlov_UUID 5</span><br></blockquote></blockquote><blockquote type="cite"><span>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.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Cheers, Andreas</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote></div></blockquote></div></body></html>