You should be able to reset the UUID by doing another writeconf with the --fsname flag. After the writeconf, you'll have to writeconf all the OSTs too.<div><br></div><div>It worked on my very simple test at least:</div>
<div><div>[root@mds1 tmp]# tunefs.lustre --writeconf --fsname=test1 /dev/loop0</div><div>checking for existing Lustre data: found CONFIGS/mountdata</div><div>Reading CONFIGS/mountdata</div><div><br></div><div>   Read previous values:</div>
<div>Target:     t1-MDT0000</div><div>Index:      0</div><div>Lustre FS:  t1</div><div>Mount type: ldiskfs</div><div>Flags:      0x5</div><div>              (MDT MGS )</div><div>Persistent mount opts: iopen_nopriv,user_xattr,errors=remount-ro</div>
<div>Parameters: mdt.group_upcall=/usr/sbin/l_getgroups</div><div><br></div><div><br></div><div>   Permanent disk data:</div><div>Target:     test1-MDT0000</div><div>Index:      0</div><div>Lustre FS:  test1</div><div>Mount type: ldiskfs</div>
<div>Flags:      0x105</div><div>              (MDT MGS writeconf )</div><div>Persistent mount opts: iopen_nopriv,user_xattr,errors=remount-ro</div><div>Parameters: mdt.group_upcall=/usr/sbin/l_getgroups</div><div><br></div>
<div>Writing CONFIGS/mountdata</div><div><br></div><div><br></div><div>HTH,</div><div>Kit</div>--<br>Kit Westneat<br>System Administrator, eSys<br><a href="mailto:kit.westneat@nyu.edu" target="_blank">kit.westneat@nyu.edu</a><br>
212-992-7647<br>
<br><br><div class="gmail_quote">On Sun, Mar 18, 2012 at 1:20 AM, Stu Midgley <span dir="ltr"><<a href="mailto:sdm900@gmail.com">sdm900@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ok, from what I can tell, the root of the problem is<br>
<br>
<br>
[root@mds001 CONFIGS]# hexdump -C p1-MDT0000  | grep -C 2 mds<br>
00002450  0b 00 00 00 04 00 00 00  12 00 00 00 00 00 00 00  |................|<br>
00002460  70 31 2d 4d 44 54 30 30  30 30 00 00 00 00 00 00  |p1-MDT0000......|<br>
00002470  6d 64 73 00 00 00 00 00  70 72 6f 64 5f 6d 64 73  |mds.....prod_mds|<br>
00002480  5f 30 30 31 5f 55 55 49  44 00 00 00 00 00 00 00  |_001_UUID.......|<br>
00002490  78 00 00 00 07 00 00 00  88 00 00 00 08 00 00 00  |x...............|<br>
--<br>
000024c0  00 00 00 00 04 00 00 00  0b 00 00 00 12 00 00 00  |................|<br>
000024d0  02 00 00 00 0b 00 00 00  70 31 2d 4d 44 54 30 30  |........p1-MDT00|<br>
000024e0  30 30 00 00 00 00 00 00  70 72 6f 64 5f 6d 64 73  |00......prod_mds|<br>
000024f0  5f 30 30 31 5f 55 55 49  44 00 00 00 00 00 00 00  |_001_UUID.......|<br>
00002500  30 00 00 00 00 00 00 00  70 31 2d 4d 44 54 30 30  |0.......p1-MDT00|<br>
<br>
[root@mds001 CONFIGS]#<br>
[root@mds001 CONFIGS]# hexdump -C /mnt/md2/CONFIGS/p1-MDT0000 | grep -C 2 mds<br>
00002450  0b 00 00 00 04 00 00 00  10 00 00 00 00 00 00 00  |................|<br>
00002460  70 31 2d 4d 44 54 30 30  30 30 00 00 00 00 00 00  |p1-MDT0000......|<br>
00002470  6d 64 73 00 00 00 00 00  70 31 2d 4d 44 54 30 30  |mds.....p1-MDT00|<br>
00002480  30 30 5f 55 55 49 44 00  70 00 00 00 07 00 00 00  |00_UUID.p.......|<br>
00002490  80 00 00 00 08 00 00 00  00 00 62 10 ff ff ff ff  |..........b.....|<br>
<br>
<br>
now if only I can get the UUID to be removed or reset...<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Sun, Mar 18, 2012 at 1:05 PM, Dr Stuart Midgley <<a href="mailto:sdm900@gmail.com">sdm900@gmail.com</a>> wrote:<br>
> hmmm… that didn't work<br>
><br>
> # tunefs.lustre --force --fsname=p1 /dev/md2<br>
> checking for existing Lustre data: found CONFIGS/mountdata<br>
> Reading CONFIGS/mountdata<br>
><br>
>   Read previous values:<br>
> Target:     p1-MDT0000<br>
> Index:      0<br>
> UUID:       prod_mds_001_UUID<br>
> Lustre FS:  p1<br>
> Mount type: ldiskfs<br>
> Flags:      0x405<br>
>              (MDT MGS )<br>
> Persistent mount opts: errors=remount-ro,iopen_nopriv,user_xattr<br>
> Parameters:<br>
><br>
> tunefs.lustre: unrecognized option `--force'<br>
> tunefs.lustre: exiting with 22 (Invalid argument)<br>
><br>
><br>
><br>
><br>
> --<br>
> Dr Stuart Midgley<br>
> <a href="mailto:sdm900@gmail.com">sdm900@gmail.com</a><br>
><br>
><br>
><br>
> On 18/03/2012, at 12:17 AM, Nathan Rutman wrote:<br>
><br>
>> Take them all down again, use tunefs.lustre --force --fsname.<br>
>><br>
>><br>
>> On Mar 17, 2012, at 2:10 AM, "Stu Midgley" <<a href="mailto:sdm900@gmail.com">sdm900@gmail.com</a>> wrote:<br>
>><br>
>>> Afternoon<br>
>>><br>
>>> We have a rather severe problem with our lustre file system.  We had a<br>
>>> full config log and the advice was to rewrite it with a new one.  So,<br>
>>> we unmounted our lustre file system off all clients, unmount all the<br>
>>> ost's and then unmounted the mds.  I then did<br>
>>><br>
>>> mds:<br>
>>>  tunefs.lustre --writeconf --erase-params /dev/md2<br>
>>><br>
>>> oss:<br>
>>>  tunefs.lustre --writeconf --erase-params --mgsnode=mds001 /dev/md2<br>
>>><br>
>>><br>
>>><br>
>>> After the tunefs.lustre on the mds I saw<br>
>>><br>
>>> Mar 17 14:33:02 mds001 kernel: Lustre: MGS MGS started<br>
>>> Mar 17 14:33:02 mds001 kernel: Lustre: MGC172.16.0.251@tcp: Reactivating import<br>
>>> Mar 17 14:33:02 mds001 kernel: Lustre: MGS: Logs for fs p1 were<br>
>>> removed by user request.  All servers must be restarted in order to<br>
>>> regenerate the logs.<br>
>>> Mar 17 14:33:02 mds001 kernel: Lustre: Enabling user_xattr<br>
>>> Mar 17 14:33:02 mds001 kernel: Lustre: p1-MDT0000: new disk, initializing<br>
>>> Mar 17 14:33:02 mds001 kernel: Lustre: p1-MDT0000: Now serving<br>
>>> p1-MDT0000 on /dev/md2 with recovery enabled<br>
>>><br>
>>> which scared me a little...<br>
>>><br>
>>><br>
>>><br>
>>> the mds and the oss's mount happily BUT I can't mount the file system<br>
>>> on my clients... on the mds I see<br>
>>><br>
>>><br>
>>> Mar 17 16:42:11 mds001 kernel: LustreError: 137-5: UUID<br>
>>> 'prod_mds_001_UUID' is not available  for connect (no target)<br>
>>><br>
>>><br>
>>> On the client I see<br>
>>><br>
>>><br>
>>> Mar 17 16:00:06 host kernel: LustreError: 11-0: an error occurred<br>
>>> while communicating with 172.16.0.251@tcp. The mds_connect operation<br>
>>> failed with -19<br>
>>><br>
>>><br>
>>> now, it appears the writeconf renamed the UUID of the mds from<br>
>>> prod_mds_001_UUID to p1-MDT0000_UUID but I can't work out how to get<br>
>>> it back...<br>
>>><br>
>>><br>
>>> for example I tried<br>
>>><br>
>>><br>
>>> # tunefs.lustre --mgs --mdt --fsname=p1 /dev/md2<br>
>>> checking for existing Lustre data: found CONFIGS/mountdata<br>
>>> Reading CONFIGS/mountdata<br>
>>><br>
>>> Read previous values:<br>
>>> Target:     p1-MDT0000<br>
>>> Index:      0<br>
>>> UUID:       prod_mds_001_UUID<br>
>>> Lustre FS:  p1<br>
>>> Mount type: ldiskfs<br>
>>> Flags:      0x405<br>
>>>            (MDT MGS )<br>
>>> Persistent mount opts: errors=remount-ro,iopen_nopriv,user_xattr<br>
>>> Parameters:<br>
>>><br>
>>> tunefs.lustre: cannot change the name of a registered target<br>
>>> tunefs.lustre: exiting with 1 (Operation not permitted)<br>
>>><br>
>>><br>
>>><br>
>>> I'm now stuck not being able to mount a 1PB file system... which isn't good :(<br>
>>><br>
>>> --<br>
>>> Dr Stuart Midgley<br>
>>> <a href="mailto:sdm900@gmail.com">sdm900@gmail.com</a><br>
>> ______________________________________________________________________<br>
>> This email may contain privileged or confidential information, which should only be used for the purpose for which it was sent by Xyratex. No further rights or licenses are granted to use such information. If you are not the intended recipient of this message, please notify the sender by return and delete it. You may not use, copy, disclose or rely on the information contained in it.<br>

>><br>
>> Internet email is susceptible to data corruption, interception and unauthorised amendment for which Xyratex does not accept liability. While we have taken reasonable precautions to ensure that this email is free of viruses, Xyratex does not accept liability for the presence of any computer viruses in this email, nor for any losses caused as a result of viruses.<br>

>><br>
>> Xyratex Technology Limited (03134912), Registered in England & Wales, Registered Office, Langstone Road, Havant, Hampshire, PO9 1SA.<br>
>><br>
>> The Xyratex group of companies also includes, Xyratex Ltd, registered in Bermuda, Xyratex International Inc, registered in California, Xyratex (Malaysia) Sdn Bhd registered in Malaysia, Xyratex Technology (Wuxi) Co Ltd registered in The People's Republic of China and Xyratex Japan Limited registered in Japan.<br>

>> ______________________________________________________________________<br>
>><br>
>><br>
><br>
<br>
<br>
<br>
--<br>
Dr Stuart Midgley<br>
<a href="mailto:sdm900@gmail.com">sdm900@gmail.com</a><br>
</div></div></blockquote></div><br></div>