https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-970 Lustre <p>We receive many messages like:</p> <p>Jan 8 04:21:55 osiride-lp-030 kernel: LustreError: 11463:0:(client.c:858:ptlrpc_import_delay_req()) @@@ IMP_INVALID req@ffff810a722ccc00 x1388786345868037/t0 o101-&gt;MGS@MGC10.121.13.31@tcp_0:26/25 lens 296/544 e 0 to 1 dl 0 ref 1 fl Rpc:/0/0 rc 0/0<br/> Jan 8 04:21:55 osiride-lp-030 kernel: LustreError: 11463:0:(client.c:858:ptlrpc_import_delay_req()) Skipped 179 previous similar messages<br/> Jan 8 04:22:38 osiride-lp-030 kernel: Lustre: 6743:0:(client.c:1487:ptlrpc_expire_one_request()) @@@ Request x1388786345868061 sent from MGC10.121.13.31@tcp to NID 0@lo 5s ago has timed out (5s prior to deadline).<br/> Jan 8 04:22:38 osiride-lp-030 kernel: req@ffff810256529800 x1388786345868061/t0 o250-&gt;MGS@MGC10.121.13.31@tcp_0:26/25 lens 368/584 e 0 to 1 dl 1325992958 ref 1 fl Rpc:N/0/0 rc 0/0<br/> Jan 8 04:22:38 osiride-lp-030 kernel: Lustre: 6743:0:(client.c:1487:ptlrpc_expire_one_request()) Skipped 100 previous similar messages</p> <p>I have attached the "messages" of the MDS/MGS server.</p> <p>Can you explain the meaning of these messages and how could we fix it?</p> Lustre version: 1.8.5.54-20110316022453-PRISTINE-2.6.18-194.17.1.el5_lustre.20110315140510<br/> lctl version: 1.8.5.54-20110316022453-PRISTINE-2.6.18-194.17.1.el5_lustre.20110315140510<br/> Red Hat Enterprise Linux Server release 5.4 (Tikanga)<br/> auth type over ldap and kerberos<br/> quota enabled only for group on lustre fs<br/> LU-970

Invalid Import messages

Bug Major Resolved Fixed Zhenyu Xu Supporto Lustre Jnet2000 log server Mon, 9 Jan 2012 05:23:05 +0000 Thu, 2 Feb 2012 13:18:06 +0000 Thu, 2 Feb 2012 13:18:06 +0000 Lustre 1.8.x (1.8.0 - 1.8.5) 0 5 <p>This means that the MDT somehow cannot reach the MGS which is supposed to run locally.<br/> Could you please run the following commands on this server and attach the output to this ticket?</p> <ul> <li>lctl dl</li> <li>lctl get_param mgc.*.import</li> </ul> <p>Also, you mentioned that you are running "1.8.5.54-20110316022453". Do i understand correctly that you are running a beta version of Oracle's 1.8.6 which isn't intended to be used in production? If so, i would really advise to upgrade to 1.8.7-wc1. </p> <p>Bobi</p> <p>Could you please take care of this ticket?</p> <p>Thanks</p> <p>Peter</p> <p><span class="error">&#91;root@osiride-lp-031 wisi281&#93;</span># lctl dl<br/> 0 UP mgc MGC10.121.13.31@tcp 326e50f4-053e-14d7-29f8-10a8ae98140d 5<br/> 1 UP ost OSS OSS_uuid 3<br/> 2 UP obdfilter home-OST0003 home-OST0003_UUID 43<br/> 3 UP mgs MGS MGS 43<br/> 4 UP mgc MGC10.121.13.62@tcp 8ac4b17d-d00e-1d89-9281-3d1615a38949 5<br/> 5 UP mdt MDS MDS_uuid 3<br/> 6 UP lov home-mdtlov home-mdtlov_UUID 4<br/> 7 UP mds home-MDT0000 home-MDT0000_UUID 41<br/> 8 UP osc home-OST0000-osc home-mdtlov_UUID 5<br/> 9 UP osc home-OST0001-osc home-mdtlov_UUID 5<br/> 10 UP osc home-OST0002-osc home-mdtlov_UUID 5<br/> 11 UP osc home-OST0003-osc home-mdtlov_UUID 5<br/> 12 UP osc home-OST0004-osc home-mdtlov_UUID 5<br/> 13 UP osc home-OST0005-osc home-mdtlov_UUID 5<br/> 14 UP osc home-OST0006-osc home-mdtlov_UUID 5<br/> 15 UP osc home-OST0007-osc home-mdtlov_UUID 5<br/> 16 UP osc home-OST0008-osc home-mdtlov_UUID 5<br/> 17 UP osc home-OST0009-osc home-mdtlov_UUID 5<br/> 18 UP osc home-OST000a-osc home-mdtlov_UUID 5<br/> 19 UP osc home-OST000b-osc home-mdtlov_UUID 5<br/> 20 UP obdfilter home-OST0000 home-OST0000_UUID 43<br/> 21 UP obdfilter home-OST0001 home-OST0001_UUID 43<br/> 22 UP obdfilter home-OST0002 home-OST0002_UUID 43<br/> 23 UP obdfilter home-OST0005 home-OST0005_UUID 43<br/> 24 UP obdfilter home-OST000a home-OST000a_UUID 43<br/> 25 UP obdfilter home-OST0008 home-OST0008_UUID 43<br/> 26 UP obdfilter home-OST0006 home-OST0006_UUID 43<br/> 27 UP obdfilter home-OST000b home-OST000b_UUID 43<br/> 28 UP obdfilter home-OST0009 home-OST0009_UUID 43<br/> 29 UP obdfilter home-OST0004 home-OST0004_UUID 43<br/> 30 UP obdfilter home-OST0007 home-OST0007_UUID 43</p> <p><span class="error">&#91;root@osiride-lp-031 wisi281&#93;</span># lctl get_param mgc.*.import<br/> mgc.MGC10.121.13.31@tcp.import=<br/> import:<br/> name: MGC10.121.13.31@tcp<br/> target: MGS<br/> state: CONNECTING<br/> connect_flags: <span class="error">&#91;version, adaptive_timeouts, fid_is_enabled&#93;</span><br/> import_flags: [ no_recov, invalid, replayable, pingable, recon_bk,<br/> last_recon]<br/> connection:<br/> failover_nids: <span class="error">&#91;10.121.13.31@tcp&#93;</span><br/> current_connection: 10.121.13.31@tcp<br/> connection_attempts: 239371<br/> generation: 478755<br/> in-progress_invalidations: 0<br/> rpcs:<br/> inflight: 1<br/> unregistering: 0<br/> timeouts: 239370<br/> avg_waittime: 0 &lt;NULL&gt;<br/> service_estimates:<br/> services: 1 sec<br/> network: 1 sec<br/> transactions:<br/> last_replay: 0<br/> peer_committed: 0<br/> last_checked: 0<br/> mgc.MGC10.121.13.62@tcp.import=<br/> import:<br/> name: MGC10.121.13.62@tcp<br/> target: MGS<br/> state: FULL<br/> connect_flags: <span class="error">&#91;version, adaptive_timeouts&#93;</span><br/> import_flags: <span class="error">&#91;pingable, recon_bk&#93;</span><br/> connection:<br/> failover_nids: <span class="error">&#91;0@lo&#93;</span><br/> current_connection: 0@lo<br/> connection_attempts: 1<br/> generation: 1<br/> in-progress_invalidations: 0<br/> rpcs:<br/> inflight: 0<br/> unregistering: 0<br/> timeouts: 0<br/> avg_waittime: 0 &lt;NULL&gt;<br/> service_estimates:<br/> services: 1 sec<br/> network: 1 sec<br/> transactions:<br/> last_replay: 0<br/> peer_committed: 0<br/> last_checked: 0<br/> <span class="error">&#91;root@osiride-lp-031 wisi281&#93;</span>#</p> <p>Hi,<br/> other information on our setup. We have two lustre servers: </p> <ul class="alternate" type="square"> <li>osiride-lp-030 -&gt;10.121.13.31</li> <li>osiride-lp-031 -&gt;10.121.13.62</li> </ul> <p>The first server hosts these services:</p> <ul class="alternate" type="square"> <li>MGS</li> <li>MDS</li> <li>OST00</li> <li>OST01</li> <li>OST02</li> </ul> <p>The second server hosts services OST03 to OST0b</p> <p>We have a dedicated 10GbE using Broadcom Corporation NetXtreme II BCM57711E 10-Gigabit PCIe</p> <p>We have a Red Hat Cluster Suite cluster to provide High Availability.</p> <p>The output of "lctl dl" and "lctl get_param mgc.*.import" is taken after a failover and all the Lustre services are hosted on the osiride-lp-031 server. We have the same messages on the osiride-lp-031. I have attached the "messages" of osiride-lp-031 before and after the failover.</p> <p>Thanks in advance</p> <p>messages of osiride-lp-031</p> <p>We are planning to upgrade to the latest GA version of Lustre at the end of January.</p> <p>Hi,<br/> Is it normal to have on the same server for 1 exported Lustre file system two mgc entries?</p> <p>&gt;&gt; 0 UP mgc MGC10.121.13.31@tcp 326e50f4-053e-14d7-29f8-10a8ae98140d 5<br/> &gt;&gt; 4 UP mgc MGC10.121.13.62@tcp 8ac4b17d-d00e-1d89-9281-3d1615a38949 5</p> <p>Thanks in advance for your support</p> <p>This indeed looks weird. Could you please run the following commands?</p> <ul> <li>"tunefs.lustre --print $dev" against all OSTs &amp; MDT devices</li> <li>"mount"</li> </ul> <p>Could be the MDT device or some OST devices being mkfs.lustre-ed with wrong "--mgsnode" argument.</p> <p>Hi Zhenyu,<br/> I'm 100% sure that there are no mkfs.lustre mistake.</p> <p>Hi Johann,<br/> this is the output of "mount" on osiride-lp-031:<br/> <span class="error">&#91;root@osiride-lp-031 ~&#93;</span># mount<br/> /dev/mapper/vg_lp-lv_root on / type ext3 (rw)<br/> proc on /proc type proc (rw)<br/> sysfs on /sys type sysfs (rw)<br/> devpts on /dev/pts type devpts (rw,gid=5,mode=620)<br/> /dev/mapper/vg_lp-lv_tmp on /tmp type ext3 (rw)<br/> /dev/mapper/vg_lp-lv_var on /var type ext3 (rw)<br/> /dev/mapper/vg_lp-lv_vartmp on /var/tmp type ext3 (rw)<br/> /dev/mapper/vg_lp-lv_varwww on /var/www type ext3 (rw)<br/> /dev/mapper/vg_lp-lv_home on /home type ext3 (rw)<br/> /dev/mapper/vg_lp-lv_varlibxen on /var/lib/xen type ext3 (rw)<br/> /dev/mapper/vg_lp-lv_varlog on /var/log type ext3 (rw)<br/> /dev/mapper/vg_lp-lv_varlibmysql on /var/lib/mysql type ext3 (rw)<br/> /dev/mapper/vg_lp-lv_tmp_work on /tmp/work type ext3 (rw)<br/> /dev/mapper/vg_lp-lv_opt on /opt type ext3 (rw)<br/> /dev/cciss/c0d0p1 on /boot type ext3 (rw)<br/> tmpfs on /dev/shm type tmpfs (rw)<br/> none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)<br/> none on /sys/kernel/config type configfs (rw)<br/> /dev/mpath/mgsp1 on /lustre/mgs type lustre (rw)<br/> /dev/mpath/mdtp1 on /lustre/mdt type lustre (rw,acl)<br/> /dev/mpath/ost00p1 on /lustre/ost00 type lustre (rw)<br/> /dev/mpath/ost01p1 on /lustre/ost01 type lustre (rw)<br/> /dev/mpath/ost02p1 on /lustre/ost02 type lustre (rw)<br/> /dev/mpath/ost03p1 on /lustre/ost03 type lustre (rw)<br/> /dev/mpath/ost05p1 on /lustre/ost05 type lustre (rw)<br/> /dev/mpath/ost10p1 on /lustre/ost10 type lustre (rw)<br/> /dev/mpath/ost08p1 on /lustre/ost08 type lustre (rw)<br/> /dev/mpath/ost06p1 on /lustre/ost06 type lustre (rw)<br/> /dev/mpath/ost11p1 on /lustre/ost11 type lustre (rw)<br/> /dev/mpath/ost09p1 on /lustre/ost09 type lustre (rw)<br/> /dev/mpath/ost04p1 on /lustre/ost04 type lustre (rw)<br/> /dev/mpath/ost07p1 on /lustre/ost07 type lustre (rw)</p> <p>I'm not able to take the output of tunefs.lustre because this problem:</p> <p><span class="error">&#91;root@osiride-lp-031 ~&#93;</span># tunefs.lustre --print /dev/mpath/ost07p1<br/> checking for existing Lustre data: not found</p> <p>tunefs.lustre FATAL: Device /dev/mpath/ost07p1 has not been formatted with<br/> mkfs.lustre<br/> tunefs.lustre: exiting with 19 (No such device)</p> <p>I try on the /dev/dm-31 that are the real block device, but I receive the same error. </p> <p>Do you think that having this two entries in the device list table is the cause of the errors that I receive in the "messages"?<br/> Is it possible that something going wrong with the failover?<br/> If I restart the lustre platforma, should I fix this problem?</p> <p>Thanks in advance </p> <p>Please umount /dev/mpath/ost07p1 and mount it as 'ldiskfs' type, and upload its "CONFIGS/mountdata" file here.</p> <p>And check whether the "Invalid Import" messages persist as ost07 is "offline" the filesystem. </p> <p>Sorry Zhenyu but I receive the tunefs.lustre error on all the lustre's block devices :</p> <p>/dev/mpath/mgsp1 on /lustre/mgs type lustre (rw)<br/> /dev/mpath/mdtp1 on /lustre/mdt type lustre (rw,acl)<br/> /dev/mpath/ost00p1 on /lustre/ost00 type lustre (rw)<br/> /dev/mpath/ost01p1 on /lustre/ost01 type lustre (rw)<br/> /dev/mpath/ost02p1 on /lustre/ost02 type lustre (rw)<br/> /dev/mpath/ost03p1 on /lustre/ost03 type lustre (rw)<br/> /dev/mpath/ost05p1 on /lustre/ost05 type lustre (rw)<br/> /dev/mpath/ost10p1 on /lustre/ost10 type lustre (rw)<br/> /dev/mpath/ost08p1 on /lustre/ost08 type lustre (rw)<br/> /dev/mpath/ost06p1 on /lustre/ost06 type lustre (rw)<br/> /dev/mpath/ost11p1 on /lustre/ost11 type lustre (rw)<br/> /dev/mpath/ost09p1 on /lustre/ost09 type lustre (rw)<br/> /dev/mpath/ost04p1 on /lustre/ost04 type lustre (rw)<br/> /dev/mpath/ost07p1 on /lustre/ost07 type lustre (rw)</p> <p>Should I use tunefs.lustre with the real scsi disk device and not on the multipathed block devices?</p> <p>Then try to tunefs.lustre upon the real scsi disk device.</p> <p>Or use </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">debugfs -R <span class="code-quote">"dump CONFIGS/mountdata /tmp/mountdata"</span> /dev/mpath/ost07p1 </pre> </div></div> <p>to dump the file and upload here.</p> <p>opps <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/wink.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>debugfs -R "dump CONFIGS/mountdata /tmp/mountdata-ost07" /dev/mpath/ost07p1</p> <p>debugfs 1.41.10.sun2 (24-Feb-2010)<br/> /dev/mpath/ost07p1: MMP: device currently active while opening filesystem<br/> dump: Filesystem not open</p> <p>This problem (i.e. debugfs cannot open the filesystem due to MMP) has been fixed in recent e2fsprogs. Could you please update the e2fsprogs package and rerun the tunefs.lustre command?<br/> The latest one is e2fsprogs-1.41.90.wc3 and can be downloaded here: <a href="http://downloads.whamcloud.com/public/e2fsprogs/latest" class="external-link" target="_blank" rel="nofollow noopener">http://downloads.whamcloud.com/public/e2fsprogs/latest</a><br/> This package can be updated while lustre is running.</p> <p>Thanks Johann,<br/> we are waiting the authorization from the end user to upgrade the e2fsprogs.</p> <p>The end-user agree to upgrade the e2fsprogs, but we should start from the test environment. I'm planning to give to you the configuration information on 17th January.</p> <p>See you soon!!!</p> <p>The end-user ask us to wait other 2 days to upgrade in production the e2fsprogs tools. </p> <p>Thanks in advance</p> <p>dumps</p> <p>Ok, we upgrade the e2fsprogs and make the dumps of the configuration. I have attached it.</p> <p>thanks in advance</p> <ol> <li>strings mgs<br/> lustre<br/> acl,iopen_nopriv,user_xattr,errors=remount-ro<br/> failover.node=10.121.13.62@tcp</li> </ol> <p>#strings mdt <br/> home<br/> home-MDT0000<br/> ...</p> <p>#strings ost*<br/> home<br/> home-OST000x ==&gt; x from 0 to b<br/> ...</p> <p>You've formatted your devices with inconsistent fsname, this could happened when you formatted the mgs device without specifying "&#45;&#45;fsname" argument where "lustre" is its default value, and you formatted the other devices with "&#45;&#45;fsname=home".</p> <p>Could be this problem the cause of the Lustre-Error that we see in the messages?<br/> How could we fix this problem?</p> <p>yes, this could cause the error message.</p> <p>You need "tunefs.lustre &#45;&#45;mgs &#45;&#45;fsname=home &lt;other options&gt; &lt;mgs device&gt;" and remount it or even all other devices as well. </p> <p>Please don't run this command for now until we can look at the output of "tunefs.lustre --print".<br/> Any chance to attach the output of this command against all lustre targets (MGS/MDT/OSTs devices)?</p> <p>Thanks in advance. </p> <p>the tunefs output</p> <p>I am afraid that you forgot to specify the failover mgsnode when formatting the OSTs &amp; MDT:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> Read previous values: Target: home-OST0000 Index: 0 Lustre FS: home Mount type: ldiskfs Flags: 0x2 (OST ) Persistent mount opts: errors=remount-ro,extents,mballoc Parameters: mgsnode=10.121.13.31@tcp failover.node=10.121.13.62@tcp ost.quota_type=ug </pre> </div></div> <p>The OSTs and MDT should be given the full list of NIDs where the MGS can run. In your case, this is both 10.121.13.31@tcp and 10.121.13.62@tcp. This explains why the targets cannot reach the MGS when this latter runs on 10.121.13.62@tcp. That's the root cause of the error messages you see.</p> <p>To fix this, you would have to do the following procedure for each OST and the MDT:</p> <ul> <li>stop the target (via unmount or the HA agent)</li> <li>run "tunefs.lustre --mgsnode=10.121.13.62@tcp ${path/to/device}"</li> <li>restart the target (with mount or HA agent)</li> </ul> <p>I also noticed that some OSTs have "failover.node=10.121.13.62@tcp" while some others have "10.121.13.31@tcp".<br/> To make sure that there is no problem with the OST/MDT failover configuration, could you please run the following command on one lustre client? "lctl get_param </p> {mdc,osc} <p>.*.import"</p> <p>the lctl get_param </p> {mdc,osc} <p>.*.import output</p> <ol> <li>grep failover_nids lustre.info<br/> failover_nids: <span class="error">&#91;10.121.13.62@tcp, 10.121.13.31@tcp&#93;</span><br/> failover_nids: <span class="error">&#91;10.121.13.62@tcp, 10.121.13.31@tcp&#93;</span><br/> failover_nids: <span class="error">&#91;10.121.13.62@tcp, 10.121.13.31@tcp&#93;</span><br/> failover_nids: <span class="error">&#91;10.121.13.62@tcp, 10.121.13.31@tcp&#93;</span><br/> failover_nids: <span class="error">&#91;10.121.13.62@tcp, 10.121.13.31@tcp&#93;</span><br/> failover_nids: <span class="error">&#91;10.121.13.62@tcp, 10.121.13.31@tcp&#93;</span><br/> failover_nids: <span class="error">&#91;10.121.13.62@tcp, 10.121.13.31@tcp&#93;</span><br/> failover_nids: <span class="error">&#91;10.121.13.62@tcp, 10.121.13.31@tcp&#93;</span><br/> failover_nids: <span class="error">&#91;10.121.13.62@tcp, 10.121.13.31@tcp&#93;</span><br/> failover_nids: <span class="error">&#91;10.121.13.62@tcp, 10.121.13.31@tcp&#93;</span><br/> failover_nids: <span class="error">&#91;10.121.13.62@tcp, 10.121.13.31@tcp&#93;</span><br/> failover_nids: <span class="error">&#91;10.121.13.62@tcp, 10.121.13.31@tcp&#93;</span><br/> failover_nids: <span class="error">&#91;10.121.13.62@tcp, 10.121.13.31@tcp&#93;</span></li> </ol> <p>The MDT/OST failover config looks fine, so you just have to fix the mgsnode issue as mentioned above.</p> <p>Johann, Should I fix the MGS configuration too?</p> <p>No, there is no need to set a fs name on a separate MGT which can handle multiple filesystems at once. My fault to mentioned the incorrect info in comment on 18/Jan/12 10:45 AM.</p> <p>Hi Johann and Zhenyu, the normal configuration is:</p> <ul class="alternate" type="square"> <li>MGT, MDT, OST0000, OST0001, OST0002 are owned by 10.121.13.31@tcp and the failover node are 10.121.13.62@tcp</li> <li>OST0003 -&gt; OST000b are owned by 10.121.13.62@tcp and the failover node are 10.121.13.31@tcp</li> </ul> <p>How should I change the configuration according this setup and to avoid the Lustre errors?</p> <p>When we take the tunefs output and the dumpfs output, we are in a failed situation, because all the targets are mounted on 10.121.13.62@tcp.</p> <p>We have the Lustre errors before and after the shutdown of the 10.121.13.31@tcp node, as you see in the messages.</p> <p>Thanks in advance</p> <p>&gt; How should I change the configuration according this setup and to avoid the Lustre errors?</p> <p>There is no need to change the configuration. Please just follow the procedure i detailed in my comment on 19/Jan/12 9:17 AM and the error messages will be gone.</p> <p>So when we start the node 10.121.13.31@tcp and rebalance the service, the Lustre error will be gone? But why we see the lustre error before the failing over of 10.121.13.31@tcp node?</p> <p>thanks in advance</p> <p>I'm afraid that we have not enough log of this incident to find out why the MGS wasn't responsive at this time.<br/> I would suggest to fix the mgsnode configuration error and then we can look at this problem if this happens again.</p> <p>Ok,<br/> we have rebalanced the services on osiride-lp030 and osiride-lp031 and restart all the client. No more Lustre error and this is the output of lctl dl command on both the servers.</p> <p><span class="error">&#91;root@osiride-lp-030 ~&#93;</span># lctl dl<br/> 0 UP mgs MGS MGS 45<br/> 1 UP mgc MGC10.121.13.31@tcp 5c2ce5e0-645a-2b58-6c0d-c5a9a11671f5 5<br/> 2 UP ost OSS OSS_uuid 3<br/> 3 UP obdfilter home-OST0001 home-OST0001_UUID 43<br/> 4 UP obdfilter home-OST0002 home-OST0002_UUID 43<br/> 5 UP obdfilter home-OST0000 home-OST0000_UUID 43<br/> 6 UP mdt MDS MDS_uuid 3<br/> 7 UP lov home-mdtlov home-mdtlov_UUID 4<br/> 8 UP mds home-MDT0000 home-MDT0000_UUID 41<br/> 9 UP osc home-OST0000-osc home-mdtlov_UUID 5<br/> 10 UP osc home-OST0001-osc home-mdtlov_UUID 5<br/> 11 UP osc home-OST0002-osc home-mdtlov_UUID 5<br/> 12 UP osc home-OST0003-osc home-mdtlov_UUID 5<br/> 13 UP osc home-OST0004-osc home-mdtlov_UUID 5<br/> 14 UP osc home-OST0005-osc home-mdtlov_UUID 5<br/> 15 UP osc home-OST0006-osc home-mdtlov_UUID 5<br/> 16 UP osc home-OST0007-osc home-mdtlov_UUID 5<br/> 17 UP osc home-OST0008-osc home-mdtlov_UUID 5<br/> 18 UP osc home-OST0009-osc home-mdtlov_UUID 5<br/> 19 UP osc home-OST000a-osc home-mdtlov_UUID 5<br/> 20 UP osc home-OST000b-osc home-mdtlov_UUID 5</p> <p><span class="error">&#91;root@osiride-lp-031 ~&#93;</span># lctl dl<br/> 0 UP mgc MGC10.121.13.31@tcp e4919e7b-230b-9ce3-910d-3ec6e1bed6fc 5<br/> 1 UP ost OSS OSS_uuid 3<br/> 2 UP obdfilter home-OST0006 home-OST0006_UUID 43<br/> 3 UP obdfilter home-OST0004 home-OST0004_UUID 43<br/> 4 UP obdfilter home-OST0007 home-OST0007_UUID 43<br/> 5 UP obdfilter home-OST0003 home-OST0003_UUID 43<br/> 6 UP obdfilter home-OST0009 home-OST0009_UUID 43<br/> 7 UP obdfilter home-OST0008 home-OST0008_UUID 43<br/> 8 UP obdfilter home-OST0005 home-OST0005_UUID 43<br/> 9 UP obdfilter home-OST000b home-OST000b_UUID 43<br/> 10 UP obdfilter home-OST000a home-OST000a_UUID 43</p> <p>Could you please close the issue? Thanks in advance</p> <p>Cool . To be clear, you've also fixed the MGS configuration with tunefs.lustre as explained in my comment on 19/Jan/12 9:17 AM, right?</p> <p>No I have not. We are planning to upgrade the version of Lustre to the latest stable. I will change the configuration during the upgrade.</p> <p>Please close this issue</p> <p>Thanks!</p> Development Epic log server Rank 1|hzvhk7: Rank (Obsolete) 6494 Severity