This morning I had to restart my secondary metadata controller (from now on: fry), only to find out that it wouldn't mount again the XSan volume it was using (/Volumes/raid5; raid5 from now on).
It was weird since it was mounted and working in the primary MDC. After checking the logs, and making sure there was no firewall issue, etc... I realized that all the LUNs that composed my volume appear now as "UNLABELED" in the XSan Admin tool.
Even in the Primary MDC (lila), the volume is mounted but the config in the XSan Admin seems lost. No labeled LUNs and no LUNs on the volumes...
I don't dare to reboot the Primary MDC since two months ago I already suffered the pain of reintalling and restoring all data.
Any clues??
I'm starting to get REALLY dissapointed with XSan performance and stability, the LUNs just became ulabeled out of the blue and now I'm fearing another data-loss.
Hi,
I have had 2 occasions where a single lun lost its label. I just relabeled the lun, and it worked again. I did not find out what caused the lost label, but I like to know it.
In your case you must give each lun the old label. If you make a mistake you have a big problem!
Regards
Donald
I know I can loose everything (would be 2nd time already), that's why I'm afraid of trying. The only lun I know for sure is the metadata one, since has a different size. The others are all the same size... 😟
I was thinking that maybe there would be a file or something relating the device and the LUN number, but the only thing I found was the LUN names on the XSan config files. For example in my volume .cfg file:
#
************************************************************************** # A disk section for defining disks in the hardware configuration.
#
**************************************************************************
[Disk metaLUN
cab0101raid01]
Status Up
Type metaLUN
cab0101raid01Type
[Disk cab0202lun03]
Status Up
Type cab0202lun03Type
[Disk cab0202lun02]
Status Up
Type cab0202lun02Type
[Disk cab0202lun01]
Status Up
Type cab0202lun01Type
[Disk cab0202lun00]
Status Up
Type cab0202lun00Type
[Disk cab0201lun03]
Status Up
Type cab0201lun03Type
[Disk cab0201lun02]
Status Up
Type cab0201lun02Type
[Disk cab0201lun01]
Status Up
Type cab0201lun01Type
[Disk cab0201lun00]
Status Up
Type cab0201lun00Type
[Disk cab0102lun03]
Status Up
Type cab0102lun03Type
[Disk cab0102lun02]
Status Up
Type cab0102lun02Type
[Disk cab0102lun01]
Status Up
Type cab0102lun01Type
[Disk cab0102lun00]
Status Up
Type cab0102lun00Type
[Disk cab0101lun02]
Status Up
Type cab0101lun02Type
[Disk cab0101lun00]
Status Up
Type cab0101lun00Type
#
************************************************************************** # A stripe section for defining stripe groups.
#
**************************************************************************
Hi,
I label with the command prompt, but I do all of the administration with the prompt. No xsan GUI on my systems.
you might have other places where you could have these info:
- the nicknames in the FC switch.
- the cvlabels file used when creating the labels. You can find this in /Library/Filesystems/Xsan/config on the system that created the luns.
- any kind of administration you keep yourself. (duh)
Goodluck
Donald
I'll check if I find a way to match their controller/serials to the physical disks, because I named all the LUNs following a pattern (cabin/controller/lun). This way I would be able to re-create the cvlabels file.
I'm afraid it was my first XSan and I didn't think of backing up the /Library/Filesystems/Xsan directory just in case.
matching the "controller#" column with the controllers WWNN I can identify the first part of the lun name. cab0101, cab0102, etc...
Now, since the first cabin and first controller are hosting the metadata drives, and those are different in size to all the other luns, I can assume that the last part of the "serial#" with the "L" matches the lun number because:
and checking again in RaidAdmin I see it's in lun 1 which matches the last part of the serial: L1
I assume that I can re-create the labels and bring it back to life again, but I don't dare to touch it unless the last machine goes down and I have no other choice.
Nice that you can locate the lunname back to the rdisk name.
Now you can create a good cvlabels file and apply them on the luns. from the adic manual:
Creating a File System Server Using CLI
Use this procedure to install the file system server using CLI.
1 Install StorNext. For instructions, refer to the chapter in the StorNext Installation Guide for UNIX
Users that applies to your operating system.
2 Write the list of system and FC disks to a file in a format recognized by the cvlabel command.
Type:
/usr/cvfs/bin/cvlabel -c > /usr/cvfs/config/cvlabels
The created file displays an entry for disk located by the /usr/cvfs/bin/cvlabel command.
CvfsDisk_UNKNOWN /dev/sdb # host 4 lun 1 sectors 639570752 ...
CvfsDisk_UNKNOWN /dev/sdc # host 4 lun 2 sectors 639570752 ...
CvfsDisk_UNKNOWN /dev/sdd # host 4 lun 3 sectors 639570752 ...
3 Edit the cvlabels file which has a list of all system and FC disks visible on the machine. Edit
the file to remove all the system disks and any FC disks you do not want labeled or are already
labeled.
4 Label the FC drives. Type:
/usr/cvfs/bin/cvlabel /user/cvfs/config/cvlabels
Note Output example shown will differ from the output you will see, but will be similar
in structure and information.
The paths and labels are not right for xsan, off course.
