<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 02:43:56 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-11446] ldiskfs inodes nlink mismatch with DNE</title>
                <link>https://jira.whamcloud.com/browse/LU-11446</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;It is easy to break ldiskfs format in a DNE system with async updates by adding extra hard links from another MDTs:&lt;/p&gt;

&lt;p&gt;1. start a DNE-enabled fs&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;[root@vm1 tests]# REFORMAT=yes MDSCOUNT=4 OSTCOUNT=4 sh llmount.sh  
...
quota/lquota options: &apos;hash_lqs_cur_bits=3&apos;
Formatting mgs, mds, osts
Format mds1: /tmp/lustre-mdt1
Format mds2: /tmp/lustre-mdt2
Format mds3: /tmp/lustre-mdt3
...
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;2. create a file on MDT0&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;[root@vm1 tests]# touch /mnt/lustre/foo                                         [root@vm1 tests]#
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;3. create a dir on another mdt.&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;[root@vm1 tests]# lfs mkdir -i 1 /mnt/lustre/mdt1                               [root@vm1 tests]#
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;4. create 20 hard links to /mnt/lustre/foo&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;[root@vm1 tests]# for x in $(seq 1 20); do ln /mnt/lustre/foo /mnt/lustre/mdt1/foo-link-$x; done
[root@vm1 tests]# ls -in /mnt/lustre/foo
144115205322833921 -rw-r--r--. 21 0 0 0 Sep 15 10:06 /mnt/lustre/foo
[root@vm1 tests]#
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;5. shutdown the fs&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;[root@vm1 tests]# MDSCOUNT=4 OSTCOUNT=4 sh llmountcleanup.sh
Stopping clients: vm1.localdomain /mnt/lustre (opts:-f)
Stopping client vm1.localdomain /mnt/lustre opts:-f
Stopping clients: vm1.localdomain /mnt/lustre2 (opts:-f)

&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;6. run e2fsck on MDT0 image.&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;[root@vm1 tests]# e2fsck -fnv /tmp/lustre-mdt1
e2fsck 1.42.13.wc6 (05-Feb-2017)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Inode 168 ref count is 21, should be 2.  Fix? no

Pass 5: Checking group summary information

lustre-MDT0000: ********** WARNING: Filesystem still has errors **********


         280 inodes used (0.28%, out of 100000)
           7 non-contiguous files (2.5%)
           0 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 1/0/0
       29638 blocks used (47.42%, out of 62500)
           0 bad blocks
           1 large file

         153 regular files
         118 directories
           0 character device files
           0 block device files
           0 fifos
           1 link
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
         272 files
[root@vm1 tests]#

&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;The inode #168 counts all links in its nlink counter, but only two links are local:&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;[root@vm1 tests]# debugfs -R &quot;ncheck 168&quot; /tmp/lustre-mdt1
debugfs 1.42.13.wc6 (05-Feb-2017)
Inode   Pathname
168     /REMOTE_PARENT_DIR/0x200000404:0x1:0x0
168     /ROOT/foo
Segmentation fault (core dumped)
[root@vm1 tests]#
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;If we start the fs again&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;[root@vm1 tests]# NOFORMAT=yes MDSCOUNT=4 OSTCOUNT=4 sh llmount.sh

&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;all 21 links are visible through lfs fid2path output:&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;[root@vm1 tests]# lfs fid2path /mnt/lustre 0x200000404:0x1:0x0
/mnt/lustre/foo
/mnt/lustre/mdt1/foo-link-1
/mnt/lustre/mdt1/foo-link-2
/mnt/lustre/mdt1/foo-link-3
/mnt/lustre/mdt1/foo-link-4
/mnt/lustre/mdt1/foo-link-5
/mnt/lustre/mdt1/foo-link-6
/mnt/lustre/mdt1/foo-link-7
/mnt/lustre/mdt1/foo-link-8
/mnt/lustre/mdt1/foo-link-9
/mnt/lustre/mdt1/foo-link-10
/mnt/lustre/mdt1/foo-link-11
/mnt/lustre/mdt1/foo-link-12
/mnt/lustre/mdt1/foo-link-13
/mnt/lustre/mdt1/foo-link-14
/mnt/lustre/mdt1/foo-link-15
/mnt/lustre/mdt1/foo-link-16
/mnt/lustre/mdt1/foo-link-17
/mnt/lustre/mdt1/foo-link-18
/mnt/lustre/mdt1/foo-link-19
/mnt/lustre/mdt1/foo-link-20
[root@vm1 tests]#

&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
        <key id="53452">LU-11446</key>
            <summary>ldiskfs inodes nlink mismatch with DNE</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="1" iconUrl="https://jira.whamcloud.com/images/icons/statuses/open.png" description="The issue is open and ready for the assignee to start work on it.">Open</status>
                    <statusCategory id="2" key="new" colorName="default"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="ablagodarenko">Artem Blagodarenko</assignee>
                                    <reporter username="zam">Alexander Zarochentsev</reporter>
                        <labels>
                            <label>dne2</label>
                    </labels>
                <created>Fri, 28 Sep 2018 16:02:00 +0000</created>
                <updated>Thu, 4 Aug 2022 21:48:30 +0000</updated>
                                            <version>Lustre 2.11.0</version>
                    <version>Lustre 2.12.0</version>
                                    <fixVersion>Lustre 2.16.0</fixVersion>
                                        <due></due>
                            <votes>0</votes>
                                    <watches>12</watches>
                                                                            <comments>
                            <comment id="235128" author="adilger" created="Thu, 18 Oct 2018 23:30:34 +0000"  >&lt;p&gt;I was able to reproduce this issue with 2.12.&lt;/p&gt;

&lt;p&gt;There will always be at least one hard link from &lt;tt&gt;REMOTE_PARENT_DIR&lt;/tt&gt; to the local inode to ensure that the inode is not deleted.  However, this is not totally robust if this remote link is removed too soon.&lt;/p&gt;

&lt;p&gt;However, I tested removing both the local (original) file and the remote hard links, and this did not cause the &lt;tt&gt;REMOTE_PARENT_DIR&lt;/tt&gt; link to be lost, so e2fsck would not delete such a file, only change the link count, so no data would be lost as a result.&lt;/p&gt;

&lt;p&gt;When &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-10329&quot; title=&quot;DNE3: REMOTE_PARENT_DIR scalability&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-10329&quot;&gt;LU-10329&lt;/a&gt; is implemented, there would be a remote link from every MDT that links to the file.  However, until such a time, creating a separate entry in &lt;tt&gt;REMOTE_PARENT_DIR&lt;/tt&gt; for every hard link would quickly cause problems in the MDT filesystem as the directory size limit is hit and/or performance slowdowns due to the huge directory size.&lt;/p&gt;

&lt;p&gt;So, I think this is a problem that e2fsck will consider the filesystem to be incorrect and repair the inode link count (and report the wrong count to the clients), but fortunately not a data-loss scenario since it has existed since at least 2.8 when DNE2 remote hard links were introduced.&lt;/p&gt;

&lt;p&gt;As a workaround, it might make sense to return &lt;tt&gt;max(i_nlink, leh_reccount)&lt;/tt&gt; to the clients for this case?&lt;/p&gt;</comment>
                            <comment id="235152" author="spitzcor" created="Fri, 19 Oct 2018 12:01:29 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.whamcloud.com/secure/ViewProfile.jspa?name=adilger&quot; class=&quot;user-hover&quot; rel=&quot;adilger&quot;&gt;adilger&lt;/a&gt;, thanks for confirming this issue for L2.12. &#160;You said that it is not a data-loss scenario. &#160;However, it can become one if e2fsck lowers the nlink count and then enough other names are unlinked. &#160;Once the nlink count hits 0 the other names become unconnected and Lustre can no longer perform fid2path.&lt;/p&gt;

&lt;p&gt;We expect that LFSCK can repair nlink, but we&apos;ve seen at least one case where it could not (but we haven&apos;t reproduced that (yet) and it is strange because LFSCK said that it did: &quot;namespace LFSCK repaired the object &lt;span class=&quot;error&quot;&gt;&amp;#91;0x300018aa1:0x1:0x0&amp;#93;&lt;/span&gt;&apos;s nlink count from 2 to &lt;em&gt;2&lt;/em&gt;: rc = 0&quot;).&lt;/p&gt;</comment>
                            <comment id="235402" author="adilger" created="Wed, 24 Oct 2018 05:40:09 +0000"  >&lt;p&gt;Cory, I agree that it might be possible to get into that situation. Strictly speaking, the REMOTE_PARENT_DIR link will not be removed, but the nlink count may hit zero after an e2fsck, but before LFSCK is run. &lt;/p&gt;

&lt;p&gt;My suggestion to fix this would be to have the mdd increase the local nlink count if it detects that the linkEA has more links than are reflected by nlink. That should &quot;correct&quot; the local nlink count (to the amount that linkEA can hold) and prevent the nlink count from becoming zero.&lt;/p&gt;

&lt;p&gt;Even better (though more complex) is to store the &quot;actual&quot; link count in linkEA or lma somewhere, and use that as the authoritative link count to return to clients, and not affect the local inode link count because of multiple hard links. We still want to keep REMOTE_PARENT_DIR, to avoid there being no local references, but we don&apos;t need to have all of the hard links. That is a much more complex solution, and probably not something to do before 2.12 as it involves changing the on-disk format and LFSCK.&lt;/p&gt;</comment>
                            <comment id="235406" author="adilger" created="Wed, 24 Oct 2018 11:47:32 +0000"  >&lt;p&gt;It may be that the better long-term strategy is the second one - the local filesystem keeps only nlink == local link count, rather than holding the whole nlink count of all remote references as well. &lt;/p&gt;

&lt;p&gt;That improves several cases:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;the need to artificially create local links to reflect the global link count&lt;/li&gt;
	&lt;li&gt;local filesystem consistency&lt;/li&gt;
	&lt;li&gt;the ability to exceed the ldiskfs filesystem nlink maximum if there are more than &lt;tt&gt;EXT4_LINK_MAX&lt;/tt&gt; (=65000) hard links&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;We would only need to store a &quot;global&quot; link count in the LMA or linkEA if there are cross-MDT hard links to the file.  That is typically very unlikely to happen, so we don&apos;t want to add overhead unless it is actually needed.&lt;/p&gt;</comment>
                            <comment id="255913" author="gerrit" created="Fri, 4 Oct 2019 15:12:45 +0000"  >&lt;p&gt;Artem Blagodarenko (c17828@cray.com) uploaded a new patch: &lt;a href=&quot;https://review.whamcloud.com/36371&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/36371&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11446&quot; title=&quot;ldiskfs inodes nlink mismatch with DNE&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11446&quot;&gt;LU-11446&lt;/a&gt; e2fsck: don&apos;t fix inodes nlink mismatch for cross-target links&lt;br/&gt;
Project: tools/e2fsprogs&lt;br/&gt;
Branch: master-lustre&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: ddf2abdebef12cd0b1296854ac722bb2dd3fb2e4&lt;/p&gt;</comment>
                            <comment id="255921" author="adilger" created="Fri, 4 Oct 2019 18:19:37 +0000"  >&lt;p&gt;Artem, have you given any thought to how we might handle this in a more transparent manner, separating the local disk nlink count from the distributed nlink count?  Using the &lt;tt&gt;leh_reccount&lt;/tt&gt; partially solves this problem, but the linkEA is not guaranteed to store all of the hard links to a file.  &lt;/p&gt;

&lt;p&gt;While &lt;tt&gt;leh_reccount&lt;/tt&gt; is a 32-bit value, it (currently) needs to match the number of entries in the list. That could possibly be fixed with some changes to the code (maybe a new magic?), and LFSCK, so &lt;tt&gt;leh_reccount&lt;/tt&gt; always stored the total number of hard links, and the list might be shorter than this. We could base the list iteration on the size of the xattr and not the link count, or add in a separate field to the linkEA, or maybe to the LMA?  Then, the MDS would not drop the last local link to a file until &lt;tt&gt;leh_recount&lt;/tt&gt; became zero, instead of trusting the inode nlink count. &lt;/p&gt;

&lt;p&gt;I don&apos;t think storing all the hard links to a file in the &lt;tt&gt;link&lt;/tt&gt; EA is practical as that will get very slow - &lt;tt&gt;65000 links x 274 bytes/link = 17MB&lt;/tt&gt; that needs to be rewritten on each update, and would break getxattr due to the size.  Even using the full 64KiB xattr would allow at most &lt;tt&gt;(65536 - 24) / (2 + 16 + 8) = 2519&lt;/tt&gt; 8-byte filenames or &lt;tt&gt;1926&lt;/tt&gt; 16-byte filenames, which is lower than we&apos;d want for the maximum nlink count. &lt;/p&gt;</comment>
                            <comment id="297215" author="gerrit" created="Tue, 30 Mar 2021 11:38:52 +0000"  >&lt;p&gt;Li Dongyang (dongyangli@ddn.com) uploaded a new patch: &lt;a href=&quot;https://review.whamcloud.com/43169&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/43169&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11446&quot; title=&quot;ldiskfs inodes nlink mismatch with DNE&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11446&quot;&gt;LU-11446&lt;/a&gt; e2fsck: reference trusted.link xattr when fixing inode nlink&lt;br/&gt;
Project: tools/e2fsprogs&lt;br/&gt;
Branch: master-lustre&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: 0b126f9655f25cfc5718fe5a9b34757377ab595f&lt;/p&gt;</comment>
                            <comment id="297620" author="adilger" created="Thu, 1 Apr 2021 23:15:28 +0000"  >&lt;p&gt;Instead of changing the existing semantics of &lt;tt&gt;leh_reccount&lt;/tt&gt; to hold the total link count it probably makes more sense to use &lt;tt&gt;reserved2&lt;/tt&gt; for &lt;tt&gt;leh_linkcount&lt;/tt&gt; to store the total number of links.  If this field is zero, then we depend on &lt;tt&gt;max(inode-&amp;gt;i_links_count, leh_reccount)&lt;/tt&gt; as the best-guess estimate of the distributed link count, but that cannot be totally accurate given the limitations on the &lt;tt&gt;trusted.link&lt;/tt&gt; xattr size.&lt;/p&gt;</comment>
                            <comment id="298157" author="gerrit" created="Wed, 7 Apr 2021 22:02:38 +0000"  >&lt;p&gt;Andreas Dilger (adilger@whamcloud.com) merged in patch &lt;a href=&quot;https://review.whamcloud.com/43169/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/43169/&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11446&quot; title=&quot;ldiskfs inodes nlink mismatch with DNE&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11446&quot;&gt;LU-11446&lt;/a&gt; e2fsck: check trusted.link when fixing nlink&lt;br/&gt;
Project: tools/e2fsprogs&lt;br/&gt;
Branch: master-lustre&lt;br/&gt;
Current Patch Set: &lt;br/&gt;
Commit: 6528bce00beaa69d1d140452b1a8b84cc7e1f253&lt;/p&gt;</comment>
                            <comment id="298159" author="adilger" created="Wed, 7 Apr 2021 22:12:23 +0000"  >&lt;p&gt;The e2fsck patch is merged into 1.45.6.wc6, but the improvement to DNE nlink handling still needs to be done, so this ticket should not be closed yet.&lt;/p&gt;</comment>
                            <comment id="298201" author="gerrit" created="Thu, 8 Apr 2021 06:43:42 +0000"  >&lt;p&gt;Li Dongyang (dongyangli@ddn.com) uploaded a new patch: &lt;a href=&quot;https://review.whamcloud.com/43231&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/43231&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11446&quot; title=&quot;ldiskfs inodes nlink mismatch with DNE&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11446&quot;&gt;LU-11446&lt;/a&gt; e2fsck: check trusted.link when fixing nlink&lt;br/&gt;
Project: tools/e2fsprogs&lt;br/&gt;
Branch: master-lustre-test&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: 4407cd4ac0595dc884a11b7b943cdb5ed9695d21&lt;/p&gt;</comment>
                            <comment id="298827" author="gerrit" created="Thu, 15 Apr 2021 02:43:31 +0000"  >&lt;p&gt;Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: &lt;a href=&quot;https://review.whamcloud.com/43324&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/43324&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11446&quot; title=&quot;ldiskfs inodes nlink mismatch with DNE&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11446&quot;&gt;LU-11446&lt;/a&gt; e2fsck: check trusted.link after linking inode&lt;br/&gt;
Project: tools/e2fsprogs&lt;br/&gt;
Branch: master-lustre&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: 8b18eecebe743a0fd3894a2818fb030994ab8533&lt;/p&gt;</comment>
                            <comment id="299386" author="gerrit" created="Wed, 21 Apr 2021 12:56:49 +0000"  >&lt;p&gt;Li Dongyang (dongyangli@ddn.com) merged in patch &lt;a href=&quot;https://review.whamcloud.com/43231/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/43231/&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11446&quot; title=&quot;ldiskfs inodes nlink mismatch with DNE&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11446&quot;&gt;LU-11446&lt;/a&gt; e2fsck: check trusted.link when fixing nlink&lt;br/&gt;
Project: tools/e2fsprogs&lt;br/&gt;
Branch: master-lustre-test&lt;br/&gt;
Current Patch Set: &lt;br/&gt;
Commit: b9cbd54b4a9c1bef0362b9b84b3ab61da0025998&lt;/p&gt;</comment>
                            <comment id="325479" author="pjones" created="Mon, 7 Feb 2022 18:29:16 +0000"  >&lt;p&gt;Is there any work remaining on this ticket?&lt;/p&gt;</comment>
                            <comment id="330259" author="artem_blagodarenko" created="Fri, 25 Mar 2022 16:27:53 +0000"  >&lt;p&gt;&amp;gt;Is there any work remaining on this ticket?&lt;br/&gt;
As Andreas said there is still work that can be done. The ideas are listed in the his posts above.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                        <issuelink>
            <issuekey id="49558">LU-10329</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="53673">LU-11549</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="53653">LU-11545</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="63725">LU-14600</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="54125">LU-11706</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </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|i003af:</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>