<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 02:41:06 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>Whamcloud Community JIRA</title>
    <link>https://jira.whamcloud.com</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.4.14</version>
        <build-number>940014</build-number>
        <build-date>05-12-2023</build-date>
    </build-info>


<item>
            <title>[LU-11119] A &apos;mv&apos; of a file from a local file system to a lustre file system hangs</title>
                <link>https://jira.whamcloud.com/browse/LU-11119</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;I have found a weird problem on our Lustre system when we try to move a file from a different file system (here /tmp) onto the lustre file server. This problem only affects a mv. A cp works ok. The problem is that the &apos;mv&apos; hangs forever, and the process can not be a killed WHen I did a strace on the mv, the program hangs on fchown.&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;strace mv /tmp/simon.small.txt  /mnt/lustre/projects/pMOSP/simon
&amp;lt;stuff&amp;gt;
write(4, &quot;1\n&quot;, 2)                      = 2
read(3, &quot;&quot;, 4194304)                    = 0
utimensat(4, NULL, [{1530777797, 478293939}, {1530777797, 478293939}], 0) = 0
fchown(4, 10001, 10025 

If you look at demsg, you see these multiple errors start appearing at the same time:
The errors don&apos;t stop as we can&apos;t kill the &apos;mv&apos; process

Thu Jul  5 18:08:43 2018] Lustre: lustre-MDT0000-mdc-ffff88351771f000: Connection restored to 172.16.231.50@o2ib (at 172.16.231.50@o2ib)
[Thu Jul  5 18:08:43 2018] Lustre: Skipped 140105 previous similar messages
[Thu Jul  5 18:09:47 2018] Lustre: lustre-MDT0000-mdc-ffff88351771f000: Connection to lustre-MDT0000 (at 172.16.231.50@o2ib) was lost; in progress operations using this service will wait for recovery to complete
[Thu Jul  5 18:09:47 2018] Lustre: Skipped 285517 previous similar messages
[Thu Jul  5 18:09:47 2018] Lustre: lustre-MDT0000-mdc-ffff88351771f000: Connection restored to 172.16.231.50@o2ib (at 172.16.231.50@o2ib)
[Thu Jul  5 18:09:47 2018] Lustre: Skipped 285516 previous similar messages
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;We have the following ofed drivers, which I believe have a known problem with connecting to Lustre servers&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;ofed_info | head -1
MLNX_OFED_LINUX-4.2-1.2.0.0 (OFED-4.2-1.2.0):
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment>uname -a&lt;br/&gt;
Linux monarch-login2 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux&lt;br/&gt;
&lt;br/&gt;
&amp;nbsp;cat /etc/redhat-release &lt;br/&gt;
CentOS Linux release 7.4.1708 (Core) &lt;br/&gt;
&lt;br/&gt;
lctl lustre_build_version&lt;br/&gt;
Lustre version: 2.10.3&lt;br/&gt;
</environment>
        <key id="52642">LU-11119</key>
            <summary>A &apos;mv&apos; of a file from a local file system to a lustre file system hangs</summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="3" iconUrl="https://jira.whamcloud.com/images/icons/priorities/major.svg">Major</priority>
                        <status id="5" iconUrl="https://jira.whamcloud.com/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="1">Fixed</resolution>
                                        <assignee username="jhammond">John Hammond</assignee>
                                    <reporter username="monash-hpc">Monash HPC</reporter>
                        <labels>
                    </labels>
                <created>Thu, 5 Jul 2018 08:22:55 +0000</created>
                <updated>Mon, 16 Nov 2020 14:26:44 +0000</updated>
                            <resolved>Mon, 16 Nov 2020 14:26:44 +0000</resolved>
                                    <version>Lustre 2.10.3</version>
                                                        <due></due>
                            <votes>0</votes>
                                    <watches>9</watches>
                                                                            <comments>
                            <comment id="229959" author="utopiabound" created="Thu, 5 Jul 2018 14:00:06 +0000"  >&lt;p&gt;Lustre said it lost connect to MDT and needs to wait for Recovery to complete. &#160;Can you attach logs from MDS?&lt;/p&gt;</comment>
                            <comment id="229969" author="jhammond" created="Thu, 5 Jul 2018 17:45:40 +0000"  >&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;Does &apos;mv&apos; consistently hang in &lt;tt&gt;fchown()&lt;/tt&gt;? Is the &apos;mv&apos; command being run by root, by the owner of the file, or some other user? From the strace output it appears to be by the file owner. Could you post the output of the &apos;id&apos; command (in the setup used to reproduce)? I noticed that the destination directory is marked SGID. Does the hang still occur if the destination directory in not marked SGID?&lt;/p&gt;

&lt;p&gt;Does the MDS use the same Lustre and kernel versions?&lt;/p&gt;</comment>
                            <comment id="229995" author="monash-hpc" created="Fri, 6 Jul 2018 07:09:13 +0000"  >&lt;p&gt;John/Nathaniels.&lt;br/&gt;
(1) &apos;mv&apos; works when ran as root&lt;br/&gt;
(2) &apos;mv&apos; always seems to fail at &lt;br/&gt;
&apos;&lt;br/&gt;
utimensat(4, NULL, [&lt;/p&gt;
{1530778053, 0}
&lt;p&gt;, &lt;/p&gt;
{1530777797, 0}
&lt;p&gt;], 0) = 0&lt;br/&gt;
fchown(4, 10001, 10060&lt;/p&gt;

&lt;p&gt;&apos;&lt;br/&gt;
(3) I went to the MDS and give you the logs below. I started the &apos;mv&apos; after 4:41 so the errors you see should begin at &quot;LustreError: 181962:0:(lod_dev.c:1414:lod_sync()) lustre-MDT0000-mdtlov: can&apos;t sync ost 12: -107&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;Fri Jul  6 16:51:04 2018&amp;#93;&lt;/span&gt; LustreError: 181962:0:(lod_dev.c:1414:lod_sync()) Skipped 8274044 previous similar messages&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;Fri Jul  6 16:51:04 2018&amp;#93;&lt;/span&gt; Lustre: lustre-MDT0000: Client 66471b3c-6a3e-724d-5030-ee8252fcfcd2 (at 172.16.230.87@o2ib) reconnecting&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;Fri Jul  6 16:51:04 2018&amp;#93;&lt;/span&gt; Lustre: Skipped 5378430 previous similar messages&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;Fri Jul  6 16:51:04 2018&amp;#93;&lt;/span&gt; Lustre: lustre-MDT0000: Connection restored to 8e150630-2b04-00b6-c100-b58229b19cac (at 172.16.230.87@o2ib)&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;Fri Jul  6 16:51:04 2018&amp;#93;&lt;/span&gt; Lustre: Skipped 5377677 previous similar messages&lt;br/&gt;
&quot;&lt;br/&gt;
(4) The id of the user is&lt;br/&gt;
id smichnow&lt;br/&gt;
uid=10001(smichnow) gid=10025(monashuniversity) groups=10025(monashuniversity),10150(systems),10052(monarch),10054(pMona0002),10057(pMona0005),10060(pMOSP),10077(pMona0006),10086(pMeRC),10130(gurobi),10151(gaussianmonash),10167(M3EarlyAdopters),10184(mc01),10206(wb82),10218(nq46),10290(avizo),10295(comsol-civil),10399(cplex),10567(gauss),10610(icm)&lt;/p&gt;

&lt;p&gt;(5) The MDS Server is&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;root@rclmddc1r14-02-e1 ~&amp;#93;&lt;/span&gt;# uname -a&lt;br/&gt;
Linux rclmddc1r14-02-e1.erc.monash.edu.au 3.10.0-693.17.1.el7_lustre.x86_64 #1 SMP Mon Feb 26 13:33:51 AEDT 2018 x86_64 x86_64 x86_64 GNU/Linux&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;root@rclmddc1r14-02-e1 ~&amp;#93;&lt;/span&gt;# cat /etc/redhat-release &lt;br/&gt;
Red Hat Enterprise Linux Server release 7.4 (Maipo)&lt;/p&gt;

&lt;p&gt;(6) THe client is&lt;br/&gt;
uname -a&lt;br/&gt;
Linux monarch-login2 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux&lt;br/&gt;
uname -a&lt;br/&gt;
Linux monarch-login2 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux&lt;/p&gt;

&lt;p&gt;(7) I removed the sticky bit&lt;br/&gt;
ls -ld /mnt/lustre/projects/pMOSP/simon/&lt;br/&gt;
drwxrwsr-x 8 smichnow pMOSP 4096 Jul  6 16:47 /mnt/lustre/projects/pMOSP/simon/&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;root@monarch-login2 etc&amp;#93;&lt;/span&gt;# chmod g-s /mnt/lustre/projects/pMOSP/simon/&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;root@monarch-login2 etc&amp;#93;&lt;/span&gt;# ls -ld /mnt/lustre/projects/pMOSP/simon/&lt;br/&gt;
drwxrwxr-x 8 smichnow pMOSP 4096 Jul  6 16:47 /mnt/lustre/projects/pMOSP/simon/&lt;br/&gt;
but the &apos;mv&apos; still broke when run as user smichnow&lt;br/&gt;
thanks&lt;br/&gt;
Simon&lt;/p&gt;

</comment>
                            <comment id="229997" author="monash-hpc" created="Fri, 6 Jul 2018 07:10:33 +0000"  >&lt;p&gt;PS I added the MDS dmesg output as an attachment&lt;/p&gt;</comment>
                            <comment id="229998" author="monash-hpc" created="Fri, 6 Jul 2018 07:20:40 +0000"  >&lt;p&gt;Also I noticed that a cp -p fails like the mv&lt;br/&gt;
cp simon.small.txt /mnt/lustre/projects/pMOSP/simon/simon.small.txt.1  &lt;br/&gt;
works but&lt;br/&gt;
 cp -p simon.small.txt /mnt/lustre/projects/pMOSP/simon/simon.small.txt.2&lt;br/&gt;
 fails i.e it hangs&lt;br/&gt;
Drilling in further, a chmod works but a chgrp fails (when ran as the user)&lt;br/&gt;
i.e.&lt;br/&gt;
chown smichnow  /mnt/lustre/projects/pMOSP/simon/simon.small.txt.3&lt;br/&gt;
OK&lt;br/&gt;
chgrp pMOSP  /mnt/lustre/projects/pMOSP/simon/simon.small.txt.3&lt;br/&gt;
fails, i.e. hangs&lt;/p&gt;

&lt;p&gt;regards&lt;br/&gt;
Simon&lt;/p&gt;</comment>
                            <comment id="230005" author="jhammond" created="Fri, 6 Jul 2018 13:30:37 +0000"  >&lt;p&gt;Hi Simon,&lt;/p&gt;

&lt;p&gt;I suspect your identity upcall is not finding the supplementary group info it needs for the chown(). Could you run &lt;tt&gt;id smichnow&lt;/tt&gt; on the MDT and post the output? How do you manage the user and groups databases? Do you use &lt;tt&gt;/etc/passwd&lt;/tt&gt; and &lt;tt&gt;/etc/group&lt;/tt&gt;, LDAP, AD, or other? Are the user and group databases on the MDT kept in sync with the rest of the cluster?&lt;/p&gt;

&lt;p&gt;The identity upcall mechanism and configuration are described at &lt;a href=&quot;http://doc.lustre.org/lustre_manual.xhtml#lustreprogramminginterfaces&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://doc.lustre.org/lustre_manual.xhtml#lustreprogramminginterfaces&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="230049" author="monash-hpc" created="Mon, 9 Jul 2018 04:26:57 +0000"  >&lt;p&gt;Dear John,&lt;br/&gt;
our identity on all nodes is managed by a LDAP server. On the client (that hangs) I see&lt;br/&gt;
*&lt;span class=&quot;error&quot;&gt;&amp;#91;smichnow@monarch-login2 tmp&amp;#93;&lt;/span&gt;$ id smichnow&lt;br/&gt;
uid=10001(smichnow) gid=10025(monashuniversity) groups=10025(monashuniversity),10150(systems),10052(monarch),10054(pMona0002),10057(pMona0005),10060(pMOSP),10077(pMona0006),10086(pMeRC),10130(gurobi),10151(gaussianmonash),10167(M3EarlyAdopters),10184(mc01),10206(wb82),10218(nq46),10290(avizo),10295(comsol-civil),10399(cplex),10567(gauss),10610(icm)*&lt;/p&gt;

&lt;p&gt;and on the metadata server&lt;br/&gt;
*&lt;span class=&quot;error&quot;&gt;&amp;#91;root@rclmddc1r14-02-e1 lustre-MDT0000&amp;#93;&lt;/span&gt;# id smichnow&lt;br/&gt;
uid=10001(smichnow) gid=10025(monashuniversity) groups=10025(monashuniversity),10610(icm),10167(M3EarlyAdopters),10151(gaussianmonash),10295(comsol-civil),10054(pMona0002),10057(pMona0005),10077(pMona0006),10052(monarch),10150(systems),10130(gurobi),10290(avizo),10399(cplex),10060(pMOSP),10086(pMeRC),10184(mc01),10206(wb82),10567(gauss),10218(nq46)*&lt;/p&gt;

&lt;p&gt;which shows the same number of groups but in a different order.&lt;/p&gt;

&lt;p&gt;*&lt;span class=&quot;error&quot;&gt;&amp;#91;root@rclmddc1r14-02-e1 lustre-MDT0000&amp;#93;&lt;/span&gt;# lctl get_param mdt.lustre-MDT0000.identity_upcall&lt;br/&gt;
mdt.lustre-MDT0000.identity_upcall=/usr/sbin/l_getidentity*&lt;/p&gt;

&lt;p&gt;and&lt;/p&gt;

&lt;p&gt;*&lt;span class=&quot;error&quot;&gt;&amp;#91;root@rclmddc1r14-02-e1 lustre-MDT0000&amp;#93;&lt;/span&gt;# l_getidentity -d 10001&lt;br/&gt;
uid=10001 gid=10025,10052,10054,10057,10060,10077,10086,10130,10150,10151,10167,10184,10206,10218,10290,10295,10399,10567,10610&lt;br/&gt;
permissions:&lt;br/&gt;
  nid			perm*&lt;/p&gt;

&lt;p&gt;regards&lt;br/&gt;
Simon&lt;/p&gt;</comment>
                            <comment id="230132" author="jhammond" created="Tue, 10 Jul 2018 19:11:40 +0000"  >&lt;p&gt;Hi Simon,&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;l_getidentity&lt;/tt&gt; does generate some logging on error but it uses the authpriv facility with an error loevel of warning. If needed then could you reconfigure syslog on the MDT to temporarily capture any logging generated by &lt;tt&gt;l_getidentity&lt;/tt&gt; when you run your reproducer and attach it here?&lt;/p&gt;

&lt;p&gt;Second, could you run your reproducer and wait until the client blocks in &lt;tt&gt;fchown()&lt;/tt&gt;,then run the attached script &lt;tt&gt;stack1&lt;/tt&gt; on the MDT (to collect and consolidate the kernel stack traces) and attach the output here?&lt;/p&gt;</comment>
                            <comment id="230162" author="monash-hpc" created="Wed, 11 Jul 2018 12:23:19 +0000"  >&lt;p&gt;John&lt;br/&gt;
I&apos;m away for a few days so will run script next week. Could you also tell me how to modify syslogger to collect l-getidentify errors &lt;/p&gt;

&lt;p&gt;Thanks&lt;br/&gt;
Simon &lt;/p&gt;</comment>
                            <comment id="230212" author="jhammond" created="Thu, 12 Jul 2018 15:03:59 +0000"  >&lt;p&gt;Hi Simon,&lt;/p&gt;

&lt;p&gt;&amp;gt; Could you also tell me how to modify syslogger to collect l-getidentify errors&lt;/p&gt;

&lt;p&gt;Sure. Do you use rsyslog? If so then you can add a line of the following form to &lt;tt&gt;/etc/rsyslog.conf&lt;/tt&gt; on the MDS:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;authpriv.warning /var/log/l_getidentity
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;Then restart rsyslog, run your reproducer, and attach the contents of &lt;tt&gt;/var/log/l_getidentity&lt;/tt&gt;. You should check that no site sensitive content ended up in that file before you attach it.&lt;/p&gt;</comment>
                            <comment id="230280" author="monash-hpc" created="Mon, 16 Jul 2018 07:13:36 +0000"  >&lt;p&gt;Dear John&lt;br/&gt;
I enabled the logging, and reran the chgrp command that hung.&lt;br/&gt;
I could not see any useful comments in the log file but I include it here. Logging started today so that part worked but nothing relating to the issue&lt;br/&gt;
regards&lt;br/&gt;
Simon&lt;/p&gt;

</comment>
                            <comment id="230282" author="monash-hpc" created="Mon, 16 Jul 2018 07:18:24 +0000"  >&lt;p&gt;John&lt;br/&gt;
the dmesg errors from the node that hangs upon a chgrp are&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;Mon Jul 16 17:14:54 2018&amp;#93;&lt;/span&gt; Lustre: lustre-MDT0000-mdc-ffff88351a566800: Connection to lustre-MDT0000 (at 172.16.231.50@o2ib) was lost; in progress operations using this service will wait for recovery to complete&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;Mon Jul 16 17:14:55 2018&amp;#93;&lt;/span&gt; Lustre: Skipped 1175070 previous similar messages&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;Mon Jul 16 17:14:55 2018&amp;#93;&lt;/span&gt; Lustre: lustre-MDT0000-mdc-ffff88351a566800: Connection restored to 172.16.231.50@o2ib (at 172.16.231.50@o2ib)&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;Mon Jul 16 17:14:55 2018&amp;#93;&lt;/span&gt; Lustre: Skipped 1175070 previous similar messages&lt;/p&gt;



&lt;p&gt;regards&lt;br/&gt;
Simon&lt;/p&gt;</comment>
                            <comment id="230289" author="jhammond" created="Mon, 16 Jul 2018 13:55:25 +0000"  >&lt;p&gt;Could you run your reproducer and wait until the client blocks in fchown(), then run the attached script stack1 on the MDT (to collect and consolidate the kernel stack traces) and attach the output here?&lt;/p&gt;</comment>
                            <comment id="230335" author="monash-hpc" created="Tue, 17 Jul 2018 07:22:13 +0000"  >&lt;p&gt;Dear John,&lt;br/&gt;
I ran the command and attached the file.&lt;br/&gt;
The client executed the command&lt;br/&gt;
strace  chgrp pMOSP /mnt/lustre/projects/pMOSP/simon/simon.small.txt.3&lt;/p&gt;

&lt;p&gt;which goes up to..&lt;/p&gt;

&lt;p&gt;read(4, &quot;\1\0\0\0\0\0\0\0L&apos;\0\0\20\0\0\0pMOSP\0*\0smichnow&quot;..., 136) = 136&lt;br/&gt;
newfstatat(AT_FDCWD, &quot;/mnt/lustre/projects/pMOSP/simon/simon.small.txt.3&quot;, &lt;/p&gt;
{st_mode=S_IFREG|0600, st_size=2, ...}
&lt;p&gt;, AT_SYMLINK_NOFOLLOW) = 0&lt;br/&gt;
fchownat(AT_FDCWD, &quot;/mnt/lustre/projects/pMOSP/simon/simon.small.txt.3&quot;, -1, 10060, 0&lt;/p&gt;


&lt;p&gt;and hangs&lt;br/&gt;
regards&lt;br/&gt;
Simon&lt;/p&gt;</comment>
                            <comment id="230349" author="jhammond" created="Tue, 17 Jul 2018 14:45:27 +0000"  >&lt;p&gt;Hi Simon,&lt;/p&gt;

&lt;p&gt;OK this is interesting. The file you attached shows that the MDT was completely idle when stack1 was run. So I&apos;m sorry to say we may have been going in the wrong direction? Could you run it on the client after chown/chgrp hangs? Could you also enable some more debugging and run the following on the client:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;lctl set_param debug=&apos;+dlmtrace rpctrace vfstrace inode trace&apos;
lctl set_param debug_mb=64
lctl clear
chgrp pMOSP /mnt/lustre/projects/pMOSP/simon/simon.small.txt.3 &amp;amp;
### Wait for chgrp to hang in fchown()
lctl dk &amp;gt; /tmp/chgrp-dk.out
strack1 &amp;gt; /tmp/chgrp-stack1.out
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;And then attach &lt;tt&gt;/tmp/chgrp-dk.out&lt;/tt&gt; and &lt;tt&gt;/tmp/chgrp-stack1.out&lt;/tt&gt;?&lt;/p&gt;</comment>
                            <comment id="230414" author="monash-hpc" created="Wed, 18 Jul 2018 04:20:13 +0000"  >&lt;p&gt;Dear John&lt;br/&gt;
I have uploaded the files to you. These were run on the client monarch-dtn&lt;br/&gt;
regards&lt;br/&gt;
Simon&lt;/p&gt;</comment>
                            <comment id="230778" author="monash-hpc" created="Mon, 23 Jul 2018 23:36:44 +0000"  >&lt;p&gt;Dear John,&lt;br/&gt;
has there been any update on the problem?&lt;br/&gt;
regards&lt;br/&gt;
Simon&lt;/p&gt;</comment>
                            <comment id="231254" author="jhammond" created="Wed, 1 Aug 2018 17:02:32 +0000"  >&lt;p&gt;Hi Simon,&lt;/p&gt;

&lt;p&gt;The attachments from the 17th show that the client is waiting for the MDT to respond. But the previously attached stack1 output from the MDT show that the server is idle. Can you do the following:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;# On the client and MDT:
lctl set_param debug=&apos;+dlmtrace rpctrace vfstrace inode trace&apos;
lctl set_param debug_mb=64
lctl clear
# On the client:
chgrp pMOSP /mnt/lustre/projects/pMOSP/simon/simon.small.txt.3 &amp;amp;
# Wait for chgrp to hang in fchown()
lctl dk &amp;gt; /tmp/client-chgrp-dk.out
strack1 &amp;gt; /tmp/client-chgrp-stack1.out
# On the MDT:
lctl dk &amp;gt; /tmp/mdt-chgrp-dk.out
strack1 &amp;gt; /tmp/mdt-chgrp-stack1.out
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                            <comment id="231307" author="monash-hpc" created="Thu, 2 Aug 2018 08:04:36 +0000"  >&lt;p&gt;Dear John&lt;br/&gt;
I uploaded 2 of the files. I am afraid I could not find the program strack1. Is this part of the lustre distribution or a tool I need to install?&lt;br/&gt;
regards&lt;br/&gt;
Simon&lt;/p&gt;</comment>
                            <comment id="231310" author="jhammond" created="Thu, 2 Aug 2018 09:58:05 +0000"  >&lt;p&gt;A copy of stack1 is attached to this ticket. You used it previously.&lt;/p&gt;</comment>
                            <comment id="231373" author="monash-hpc" created="Fri, 3 Aug 2018 07:19:48 +0000"  >&lt;p&gt;John,&lt;br/&gt;
Firstly I&apos;d like to note that when I tried running the chgrp command, the OS became unstable and crashed on me. This has happened twice on me:&lt;/p&gt;

&lt;p&gt;*Message from syslogd@monarch-login2 at Aug  3 17:06:27 ...&lt;br/&gt;
 kernel:LustreError: 12556:0:(niobuf.c:330:ptlrpc_register_bulk()) ASSERTION( desc-&amp;gt;bd_md_count == 0 ) failed: &lt;/p&gt;

&lt;p&gt;Message from syslogd@monarch-login2 at Aug  3 17:06:27 ...&lt;br/&gt;
 kernel:LustreError: 12556:0:(niobuf.c:330:ptlrpc_register_bulk()) LBUG*&lt;/p&gt;

&lt;p&gt;Would you be interested in any of the contents of the /var/crash directories, i.e either the large vmcore or the vmcore-dmesg files? This may/may not be related to another bug we have in lustre which crashes our machines regularly. I am led to believe that bug is caused by an issue with the current version of mofed drivers.&lt;/p&gt;

&lt;p&gt;I ran the jobs an have uploaded the files for you, with the Aug4 postfix on them.  &lt;br/&gt;
regards Simon&lt;/p&gt;</comment>
                            <comment id="231393" author="jhammond" created="Fri, 3 Aug 2018 14:52:08 +0000"  >&lt;p&gt;OK this is better. The chgrp is failing because the MDT is not connected to OST000c. What is the status of that OST? It appears that the client and server are not handling this condition correctly.&lt;/p&gt;

&lt;p&gt;The MDT logs you provided are not from Lustre 2.10.3. What version of Lustre is the MDT running?&lt;/p&gt;

&lt;p&gt;The failed assertions are due to &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-8573&quot; title=&quot;IOR: niobuf.c:319:ptlrpc_register_bulk()) ASSERTION( desc-&amp;gt;bd_md_count == 0 ) failed&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-8573&quot;&gt;&lt;del&gt;LU-8573&lt;/del&gt;&lt;/a&gt; and possibly OFED issues.&lt;/p&gt;
</comment>
                            <comment id="231485" author="monash-hpc" created="Mon, 6 Aug 2018 07:21:18 +0000"  >&lt;p&gt;Dear John,&lt;br/&gt;
we have been updating our mofed drivers and lustre client versions to try and resolve both bugs. So some clients are &lt;br/&gt;
lctl lustre_build_version&lt;br/&gt;
Lustre version: 2.10.3&lt;/p&gt;

&lt;p&gt;and some&lt;br/&gt;
 lctl lustre_build_version&lt;br/&gt;
Lustre version: 2.10.4&lt;/p&gt;

&lt;p&gt;Both versions show this problem.&lt;/p&gt;

&lt;p&gt;As for the OST000c, this is an inactive OST&lt;br/&gt;
 lfs osts&lt;br/&gt;
OBDS:&lt;br/&gt;
0: lustre-OST0000_UUID ACTIVE&lt;br/&gt;
1: lustre-OST0001_UUID ACTIVE&lt;br/&gt;
2: lustre-OST0002_UUID ACTIVE&lt;br/&gt;
3: lustre-OST0003_UUID ACTIVE&lt;br/&gt;
4: lustre-OST0004_UUID ACTIVE&lt;br/&gt;
5: lustre-OST0005_UUID ACTIVE&lt;br/&gt;
6: lustre-OST0006_UUID ACTIVE&lt;br/&gt;
7: lustre-OST0007_UUID ACTIVE&lt;br/&gt;
8: lustre-OST0008_UUID ACTIVE&lt;br/&gt;
9: lustre-OST0009_UUID ACTIVE&lt;br/&gt;
10: lustre-OST000a_UUID ACTIVE&lt;br/&gt;
11: lustre-OST000b_UUID ACTIVE&lt;br/&gt;
&lt;b&gt;12: lustre-OST000c_UUID INACTIVE&lt;/b&gt;&lt;br/&gt;
13: lustre-OST000d_UUID ACTIVE&lt;br/&gt;
14: lustre-OST000e_UUID ACTIVE&lt;/p&gt;

&lt;p&gt;But the file belongs on a different OST ( I ran some code I found on the internet to find this)&lt;br/&gt;
/mnt/lustre/projects/pMOSP/simon/simon.small.txt.3: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;#39;lustre-OST0009&amp;#39;&amp;#93;&lt;/span&gt; &lt;/p&gt;

&lt;p&gt;The MDT Lustre version is&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;root@rclmddc1r14-02-e1 ~&amp;#93;&lt;/span&gt;# lctl lustre_build_version&lt;br/&gt;
Lustre version: 2.10.58_46_ge528677&lt;/p&gt;

&lt;p&gt;regards&lt;br/&gt;
Simon&lt;/p&gt;</comment>
                            <comment id="231865" author="jhammond" created="Mon, 13 Aug 2018 15:20:41 +0000"  >&lt;p&gt;Hi Simon,&lt;/p&gt;

&lt;p&gt;Is OST000c offline or just deactivated to prevent new files from being created on it?&lt;/p&gt;

&lt;p&gt;If it&apos;s only to prevent new files from being created then you should use the &lt;tt&gt;max_create_count&lt;/tt&gt; parameter. See &lt;a href=&quot;http://doc.lustre.org/lustre_manual.xhtml#section_remove_ost&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://doc.lustre.org/lustre_manual.xhtml#section_remove_ost&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="231923" author="jwallior" created="Tue, 14 Aug 2018 14:27:54 +0000"  >&lt;p&gt;Simon, John,&lt;br/&gt;
 We had a similar (same?) issue on 2.10.4 servers/2.10.1 clients. We applied the patch from &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11227&quot; title=&quot;client process hangs when lod_sync accesses deactivated OSTs&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11227&quot;&gt;&lt;del&gt;LU-11227&lt;/del&gt;&lt;/a&gt; and it seems good now.&lt;/p&gt;

&lt;p&gt;Regarding the assertion(bd_md_count==0), how does your trace look like? Do you have the {client,server}_bulk_callback() LustreErrors like in &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-8573&quot; title=&quot;IOR: niobuf.c:319:ptlrpc_register_bulk()) ASSERTION( desc-&amp;gt;bd_md_count == 0 ) failed&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-8573&quot;&gt;&lt;del&gt;LU-8573&lt;/del&gt;&lt;/a&gt;? We were having this assertion too (before patching with &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11227&quot; title=&quot;client process hangs when lod_sync accesses deactivated OSTs&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11227&quot;&gt;&lt;del&gt;LU-11227&lt;/del&gt;&lt;/a&gt;), but the trace looks a bit different than &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-8573&quot; title=&quot;IOR: niobuf.c:319:ptlrpc_register_bulk()) ASSERTION( desc-&amp;gt;bd_md_count == 0 ) failed&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-8573&quot;&gt;&lt;del&gt;LU-8573&lt;/del&gt;&lt;/a&gt; and no bulk_callback() LustreError.&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;[ 142.947358] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8100471d&amp;gt;&amp;#93;&lt;/span&gt; dump_trace+0x7d/0x2d0&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947369] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0b4176a&amp;gt;&amp;#93;&lt;/span&gt; libcfs_call_trace+0x4a/0x60 &lt;span class=&quot;error&quot;&gt;&amp;#91;libcfs&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947388] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0b417e8&amp;gt;&amp;#93;&lt;/span&gt; lbug_with_loc+0x48/0xa0 &lt;span class=&quot;error&quot;&gt;&amp;#91;libcfs&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947427] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0ece3c4&amp;gt;&amp;#93;&lt;/span&gt; ptlrpc_register_bulk+0x7c4/0x990 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947462] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0ecef26&amp;gt;&amp;#93;&lt;/span&gt; ptl_send_rpc+0x236/0xe20 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947497] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0ec984c&amp;gt;&amp;#93;&lt;/span&gt; ptlrpc_check_set.part.23+0x18bc/0x1dd0 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947531] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0eca2b1&amp;gt;&amp;#93;&lt;/span&gt; ptlrpc_set_wait+0x481/0x8a0 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947563] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0eca74c&amp;gt;&amp;#93;&lt;/span&gt; ptlrpc_queue_wait+0x7c/0x220 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947586] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0e630fb&amp;gt;&amp;#93;&lt;/span&gt; mdc_getpage+0x18b/0x620 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdc&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947592] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0e636ab&amp;gt;&amp;#93;&lt;/span&gt; mdc_read_page_remote+0x11b/0x650 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdc&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947598] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8113ea0e&amp;gt;&amp;#93;&lt;/span&gt; do_read_cache_page+0x7e/0x1c0&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947602] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0e5eb07&amp;gt;&amp;#93;&lt;/span&gt; mdc_read_page+0x167/0x960 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdc&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947610] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa10010ce&amp;gt;&amp;#93;&lt;/span&gt; lmv_read_page+0x1ae/0x520 &lt;span class=&quot;error&quot;&gt;&amp;#91;lmv&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947628] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa10964d0&amp;gt;&amp;#93;&lt;/span&gt; ll_get_dir_page+0xb0/0x350 &lt;span class=&quot;error&quot;&gt;&amp;#91;lustre&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947637] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa10968c9&amp;gt;&amp;#93;&lt;/span&gt; ll_dir_read+0x99/0x310 &lt;span class=&quot;error&quot;&gt;&amp;#91;lustre&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947648] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa10c9cf0&amp;gt;&amp;#93;&lt;/span&gt; ll_get_name+0x110/0x2d0 &lt;span class=&quot;error&quot;&gt;&amp;#91;lustre&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947660] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8121b3b2&amp;gt;&amp;#93;&lt;/span&gt; exportfs_get_name+0x32/0x50&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947663] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8121b526&amp;gt;&amp;#93;&lt;/span&gt; reconnect_path+0x156/0x2e0&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947666] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8121b9df&amp;gt;&amp;#93;&lt;/span&gt; exportfs_decode_fh+0xef/0x2c0&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947684] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa04cd425&amp;gt;&amp;#93;&lt;/span&gt; fh_verify+0x2f5/0x5e0 &lt;span class=&quot;error&quot;&gt;&amp;#91;nfsd&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947694] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa04d142c&amp;gt;&amp;#93;&lt;/span&gt; nfsd_access+0x2c/0x140 &lt;span class=&quot;error&quot;&gt;&amp;#91;nfsd&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947705] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa04d7378&amp;gt;&amp;#93;&lt;/span&gt; nfsd3_proc_access+0x68/0xb0 &lt;span class=&quot;error&quot;&gt;&amp;#91;nfsd&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947719] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa04c9cc2&amp;gt;&amp;#93;&lt;/span&gt; nfsd_dispatch+0xb2/0x200 &lt;span class=&quot;error&quot;&gt;&amp;#91;nfsd&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947734] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0320cab&amp;gt;&amp;#93;&lt;/span&gt; svc_process_common+0x43b/0x680 &lt;span class=&quot;error&quot;&gt;&amp;#91;sunrpc&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947754] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0320ffc&amp;gt;&amp;#93;&lt;/span&gt; svc_process+0x10c/0x160 &lt;span class=&quot;error&quot;&gt;&amp;#91;sunrpc&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947770] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa04c96cf&amp;gt;&amp;#93;&lt;/span&gt; nfsd+0xaf/0x120 &lt;span class=&quot;error&quot;&gt;&amp;#91;nfsd&amp;#93;&lt;/span&gt;&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947775] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8107ae74&amp;gt;&amp;#93;&lt;/span&gt; kthread+0xb4/0xc0&lt;/tt&gt;&lt;br/&gt;
 &lt;tt&gt;[ 142.947780] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8152ae18&amp;gt;&amp;#93;&lt;/span&gt; ret_from_fork+0x58/0x90&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="232904" author="pjones" created="Sat, 1 Sep 2018 14:14:27 +0000"  >&lt;p&gt;Simon&lt;/p&gt;

&lt;p&gt;JFYI- the above-mentioned fix for &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11227&quot; title=&quot;client process hangs when lod_sync accesses deactivated OSTs&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11227&quot;&gt;&lt;del&gt;LU-11227&lt;/del&gt;&lt;/a&gt; was included in the recently release Lustre 2.10.5.&lt;/p&gt;

&lt;p&gt;Peter&lt;/p&gt;</comment>
                            <comment id="233075" author="mhaakddn" created="Thu, 6 Sep 2018 00:00:54 +0000"  >&lt;p&gt;Hi Peter,&lt;/p&gt;

&lt;p&gt;Which commit ID? I looked at the git log for the 2.10.5 tag and could not see a commit claiming to pull this fix.&lt;/p&gt;

&lt;p&gt;Was it merged into a different commit?&lt;/p&gt;</comment>
                            <comment id="233076" author="pjones" created="Thu, 6 Sep 2018 00:32:14 +0000"  >&lt;p&gt;Ah. I apologize - it is not actually in 2.10.5. We had discussed including it but decided against it in the end because at the time it had not had very long in testing. It should be in 2.10.6&lt;/p&gt;</comment>
                            <comment id="233077" author="mhaakddn" created="Thu, 6 Sep 2018 00:46:01 +0000"  >&lt;p&gt;Hi Peter,&lt;/p&gt;

&lt;p&gt;All good. Just though I might have been going crazy was all &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.whamcloud.com/images/icons/emoticons/biggrin.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                            <comment id="233153" author="mhaakddn" created="Thu, 6 Sep 2018 23:33:53 +0000"  >&lt;p&gt;Also Peter,&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11227&quot; title=&quot;client process hangs when lod_sync accesses deactivated OSTs&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11227&quot;&gt;&lt;del&gt;LU-11227&lt;/del&gt;&lt;/a&gt; is on the list on the change log page for 2.10.5&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://wiki.lustre.org/Lustre_2.10.5_Changelog&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://wiki.lustre.org/Lustre_2.10.5_Changelog&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Thanks&lt;/p&gt;</comment>
                            <comment id="233154" author="pjones" created="Fri, 7 Sep 2018 00:00:39 +0000"  >&lt;p&gt;Not any more - thx &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.whamcloud.com/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                            <comment id="285207" author="icostelloddn" created="Mon, 16 Nov 2020 03:16:13 +0000"  >&lt;p&gt;Hi Peter,&lt;/p&gt;

&lt;p&gt;Problem resolved, we can close this one.&lt;/p&gt;

&lt;p&gt;Thanks,&lt;br/&gt;
Ian&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                        <issuelink>
            <issuekey id="49513">LU-10310</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="52928">LU-11227</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="52952">LU-11236</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                            <attachment id="30522" name="chgrp-dk-wed18july.out" size="3608656" author="monash-hpc" created="Wed, 18 Jul 2018 04:19:23 +0000"/>
                            <attachment id="30521" name="chgrp-stack1-wed18July.out" size="15317" author="monash-hpc" created="Wed, 18 Jul 2018 04:19:22 +0000"/>
                            <attachment id="30697" name="client-chgrp-dk-2Aug.out" size="16547262" author="monash-hpc" created="Thu, 2 Aug 2018 08:03:42 +0000"/>
                            <attachment id="30703" name="client-chgrp-dk.4aug.out" size="7730701" author="monash-hpc" created="Fri, 3 Aug 2018 07:20:05 +0000"/>
                            <attachment id="30702" name="client-chgrp-stack1.4aug.out" size="15186" author="monash-hpc" created="Fri, 3 Aug 2018 07:19:59 +0000"/>
                            <attachment id="30479" name="dmesg.MDS.4.47.6july.txt" size="1149935" author="monash-hpc" created="Fri, 6 Jul 2018 07:09:54 +0000"/>
                            <attachment id="30476" name="dmesg.txt" size="5761" author="monash-hpc" created="Thu, 5 Jul 2018 08:17:36 +0000"/>
                            <attachment id="30511" name="l_getidentity" size="240123" author="monash-hpc" created="Mon, 16 Jul 2018 07:17:29 +0000"/>
                            <attachment id="30696" name="mdt-chgrp-dk-2Aug.out" size="21240568" author="monash-hpc" created="Thu, 2 Aug 2018 08:04:41 +0000"/>
                            <attachment id="30701" name="mdt-chgrp-dk.4Aug.out" size="23590445" author="monash-hpc" created="Fri, 3 Aug 2018 07:20:06 +0000"/>
                            <attachment id="30700" name="mdt-chgrp-stack1.4Aug.out" size="24307" author="monash-hpc" created="Fri, 3 Aug 2018 07:19:59 +0000"/>
                            <attachment id="30517" name="output.Tue.17.july.18.txt" size="24241" author="monash-hpc" created="Tue, 17 Jul 2018 07:19:23 +0000"/>
                            <attachment id="30488" name="stack1" size="1289" author="jhammond" created="Tue, 10 Jul 2018 16:11:08 +0000"/>
                            <attachment id="30477" name="strace.output.txt" size="14781" author="monash-hpc" created="Thu, 5 Jul 2018 08:16:25 +0000"/>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                            <customfield id="customfield_10890" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10390" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hzzyrz:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9223372036854775807</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10060" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Severity</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10022"><![CDATA[3]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        </customfields>
    </item>
</channel>
</rss>