HP StorageWorks Scalable File Share - Manual (Page 46)

4. Manually mount mgs on the MGS node:
# mount /mnt/mgs
5. Manually mount mds on the MDS node:
# mount /mnt/mds
In the MDS /var/log/messages file, look for a message similar to the following:
kernel: Lustre: Setting parameter testfs-MDT0000.mdt.group_upcall in log testfs-MDT0000
This indicates the change has been successfully made.
6. unmount /mnt/mdt and /mnt/mgs from MDT and MDS respectively.
7. Restart the SFS server in the normal way using heartbeat.
It will take some time for the OSSs to rebuild the configuration data and to reconnect with the
MDS. Once they do, the client nodes can mount the Lustre file systems. On the MDS, watch the
messages file for the following entries for each OST:
mds kernel: Lustre: MDS testfs-MDT0000: testfs-OST0001_UUID now active, resetting orphans
7.6 Configuring the mlocate Package on Client Nodes
The mlocate package might be installed on your system. This package is typically set up to run
as a periodic job under the cron daemon. To prevent the possibility of a find command executing
on the global file system of all clients simultaneously, we recommend adding lustre to the list of
file system types that mlocate will ignore. Do this by adding lustre to the PRUNEFS list in /etc/
updatedb.conf
.
7.7 Multipath Performance Optimization
To configure multipath load balancing for maximum performance, the /sbin/multipath -v0
command must be executed each time a Lustre file system server boots. This optimization can
improve performance by as much as 25%. This command can be executed automatically by
entering the following command one time on each server, which will add the command to the
local startup script:
echo "/sbin/multipath -v0" >> /etc/rc.d/rc.local
The command will then run on each subsequent boot.
7.8 System Behavior After LBUG
A severe Lustre software bug, or LBUG, may occur occasionally on file system servers or clients.
The presence of an LBUG can be identified by the string LBUG in dmesg or /var/log/messages
output for the currently booted system. While a system can continue to operate after some LBUGs,
a system that has encountered an LBUG should be rebooted at the earliest opportunity. By default,
a system will not panic when an LBUG is encountered. If you want a panic to take place when
an LBUG is seen, run the following command one time on a server or client before Lustre has
been started. This line will then be added to your /etc/modprobe.conf file:
echo "options libcfs libcfs_panic_on_lbug=1" >> /etc/modprobe.conf
After this change, the panic on LBUG behavior will be enabled the next time Lustre is started,
or the system is booted.
46 Known Issues and Workarounds