<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
OK, made new raid, made file system with same index, but they won't
mount. This is the error. What can I do here?<br>
<br>
bob<br>
<br>
mounting device /dev/sdc at /mnt/ost12, flags=0
options=device=/dev/sdc<br>
mount.lustre: mount /dev/sdc at /mnt/ost12 failed: Address already
in use retries left: 0<br>
mount.lustre: mount /dev/sdc at /mnt/ost12 failed: Address already
in use<br>
The target service's index is already in use. (/dev/sdc)<br>
<br>
<br>
On 11/8/2010 5:01 AM, Andreas Dilger wrote:
<blockquote
cite="mid:11CEEF2B-ADE0-438E-AB87-1AE148C6F3AE@oracle.com"
type="cite">
<div><span class="Apple-style-span" style="">On 2010-11-07, at
12:32, Bob Ball <<a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</blockquote>
</body>
</html>