[lustre-discuss] Target names changing when mounting

[Andrus, Brian Contractor]

I use multipathing and the labels actually work well. They are merely links to the dm-xx device.

You know one of the other issues is when you use /etc/ldev.conf to map your mounts....
You see when you start lustre using the init script, it goes through that file and uses the label to help identify the mount. If it doesn't match it throws a fit. And if you just did a writeconf, it won't match....


Brian Andrus
ITACS/Research Computing
Naval Postgraduate School
Monterey, California
voice: 831-656-6238




-----Original Message-----
From: Mohr Jr, Richard Frank (Rick Mohr) [mailto:rmohr at utk.edu] 
Sent: Friday, July 31, 2015 12:09 PM
To: Drokin, Oleg
Cc: Andrus, Brian Contractor; lustre-discuss at lists.lustre.org
Subject: Re: [lustre-discuss] Target names changing when mounting


> On Jul 31, 2015, at 2:49 PM, Drokin, Oleg <oleg.drokin at intel.com> wrote:
> 
> Well, using those symlinks was certainly not expected when this code was written.
> So I imagine avoid using them and perhaps use /dev/disk/by-uuid which 
> should be more stable in the face of writeconfs

For sites using multipath, the by-label device won’t be used because (if I recall correctly) this can lead to some problems.  So in that case, this issue would not be seen.  For setups without multipath, using the by-label device can be incredibly convenient (and makes it a lot easier to tell which device corresponds to which OST).

But for me, the more confusing aspect was the discrepancy of the names in the tunefs output:

>>>  Read previous values:
>>> Target:     WORK2-MDT0000
>>> 
>>>  Permanent disk data:
>>> Target:     WORK2:MDT0000

It looks like the Lustre code reads the label, and if it sees a “:” or “=“, it sets an appropriate flag.  But then it also modifies the string internally to replace “:” or “=“ with a “-“ character.  This modified string seems to get printed for the “previous value” section, but the original unmodified string gets printed for the “permanent value” section.  I think at the very least those strings should match.

--
Rick Mohr
Senior HPC System Administrator
National Institute for Computational Sciences http://www.nics.tennessee.edu