<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:31:19 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-3140] fid sequence may reused for different objects.</title>
                <link>https://jira.whamcloud.com/browse/LU-3140</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;While investing a Cray issues we create a debug patch to verify a correct mode assigned to the md object after revalidating, but result is very confusing.&lt;/p&gt;

&lt;p&gt;same fid assigned to the different files.&lt;/p&gt;

&lt;p&gt;00000004:00000002:2.0:1365510202.512393:0:19372:0:(mdt_reint.c:281:mdt_md_create()) @@@ Create  (bdir-&amp;gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;0x200000bd0:0x1:0x0&amp;#93;&lt;/span&gt;) in &lt;span class=&quot;error&quot;&gt;&amp;#91;0x200000400:0x7:0x0&amp;#93;&lt;/span&gt;  req@ffff880036324928 x1431841008517781/t0(17179869191) o36-&amp;gt;1e287f29-a399-fb10-7bd0-d9d83ebc1ce1@0@lo:0/0 lens 456/536 e 0 to 0 dl 1365510223 ref 1 fl Complete:/4/0 rc 0/0&lt;/p&gt;

&lt;p&gt;00000004:00000002:6.0:1365510375.912867:0:23947:0:(mdt_reint.c:281:mdt_md_create()) @@@ Create  (f9-2-&amp;gt;&lt;span class=&quot;error&quot;&gt;&amp;#91;0x200000bd0:0x1:0x0&amp;#93;&lt;/span&gt;) in &lt;span class=&quot;error&quot;&gt;&amp;#91;0x61ab:0x54d71902:0x0&amp;#93;&lt;/span&gt;  req@ffff88002a88c008 x1431841008518517/t0(0) o36-&amp;gt;e35c9b0d-1221-a3ae-0357-637f30903536@0@lo:0/0 lens 456/536 e 0 to 0 dl 1365510395 ref 1 fl Interpret:/0/0 rc 0/0&lt;/p&gt;

&lt;p&gt;as you see - bdir and f9-2 have a same fid.&lt;/p&gt;

&lt;p&gt;replicating a very easy &lt;br/&gt;
1) apply an patch (to hit assert and panic) or dump log after test loop.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;bash-3.2$ git diff
diff --git a/lustre/llite/llite_lib.c b/lustre/llite/llite_lib.c
index 7dad8f9..c40cfd2 100644
--- a/lustre/llite/llite_lib.c
+++ b/lustre/llite/llite_lib.c
@@ -1654,6 +1654,20 @@ void ll_update_inode(struct inode *inode, struct lustre_md *md)
 &#160; &#160; &#160; &#160; struct ll_sb_info *sbi = ll_i2sbi(inode);
 
 &#160; &#160; &#160; &#160; LASSERT ((lsm != NULL) == ((body-&amp;gt;valid &amp;amp; OBD_MD_FLEASIZE) != 0));
+ &#160; &#160; &#160; &#160;&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (body-&amp;gt;valid &amp;amp; OBD_MD_FLTYPE) {
+ &#160; &#160; &#160; &#160; &#160; &#160; &#160; &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; ((!S_ISDIR(inode-&amp;gt;i_mode) &amp;amp;&amp;amp; S_ISDIR(body-&amp;gt;mode)) ||
+ &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; (S_ISDIR(inode-&amp;gt;i_mode) &amp;amp;&amp;amp; !S_ISDIR(body-&amp;gt;mode))) {
+&lt;span class=&quot;code-comment&quot;&gt;// &#160; &#160; &#160; &#160; &#160; &#160; &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; ((inode-&amp;gt;i_mode &amp;amp; S_IFMT) != (body-&amp;gt;mode &amp;amp; S_IFMT)) {
&lt;/span&gt;+ &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; CERROR(&lt;span class=&quot;code-quote&quot;&gt;&quot;ino %p-&amp;gt;%lu type is %s but server reply has %s &quot;&lt;/span&gt;
+ &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160;&lt;span class=&quot;code-quote&quot;&gt;&quot;type (%o and %o). FID &quot;&lt;/span&gt;DFID&lt;span class=&quot;code-quote&quot;&gt;&quot;\n&quot;&lt;/span&gt;, inode, inode-&amp;gt;i_ino,
+ &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160;S_ISDIR(inode-&amp;gt;i_mode) ? &lt;span class=&quot;code-quote&quot;&gt;&quot;directory&quot;&lt;/span&gt; :&lt;span class=&quot;code-quote&quot;&gt;&quot;file&quot;&lt;/span&gt;,
+ &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160;S_ISDIR(body-&amp;gt;mode) ? &lt;span class=&quot;code-quote&quot;&gt;&quot;directory&quot;&lt;/span&gt; : &lt;span class=&quot;code-quote&quot;&gt;&quot;file&quot;&lt;/span&gt;,
+ &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160;inode-&amp;gt;i_mode &amp;amp; S_IFMT, body-&amp;gt;mode &amp;amp; S_IFMT,
+ &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160;PFID(&amp;amp;lli-&amp;gt;lli_fid));
+ &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; LBUG();
+ &#160; &#160; &#160; &#160; &#160; &#160; &#160; }
+ &#160; &#160; &#160; }
+
 &#160; &#160; &#160; &#160; &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (lsm != NULL) {
 &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; LASSERT(S_ISREG(inode-&amp;gt;i_mode));
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;2) run PTLDEBUG=-1 SUBSYSTEM=-1 DEBUG_SIZE=400 llmount.sh to setup a single node lustre cluster&lt;/p&gt;

&lt;p&gt;3) run a replay-dual with simple script.&lt;br/&gt;
for ((i=0; i!=1000; i++)) do&lt;br/&gt;
for ((j=1; j!=10; j++)) do&lt;br/&gt;
echo &quot;Iteration $i&quot;&lt;br/&gt;
SLOW=YES  ONLY=$j DIR=/mnt/lustre sh ./replay-dual.sh&lt;br/&gt;
done&lt;br/&gt;
done&lt;/p&gt;

&lt;p&gt;in 90% times you have hit a bug after first loop.&lt;/p&gt;
</description>
                <environment>single node setup.</environment>
        <key id="18311">LU-3140</key>
            <summary>fid sequence may reused for different objects.</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="6" iconUrl="https://jira.whamcloud.com/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="5">Cannot Reproduce</resolution>
                                        <assignee username="tappro">Mikhail Pershin</assignee>
                                    <reporter username="shadow">Alexey Lyashkov</reporter>
                        <labels>
                    </labels>
                <created>Wed, 10 Apr 2013 05:09:24 +0000</created>
                <updated>Sun, 22 Jul 2018 09:14:42 +0000</updated>
                            <resolved>Sun, 22 Jul 2018 09:14:42 +0000</resolved>
                                    <version>Lustre 2.1.0</version>
                    <version>Lustre 2.2.0</version>
                    <version>Lustre 2.3.0</version>
                    <version>Lustre 2.4.0</version>
                                                        <due></due>
                            <votes>0</votes>
                                    <watches>12</watches>
                                                                            <comments>
                            <comment id="55959" author="shadow" created="Wed, 10 Apr 2013 05:17:40 +0000"  >&lt;p&gt;full debug log from hit assert.&lt;/p&gt;</comment>
                            <comment id="55960" author="bzzz" created="Wed, 10 Apr 2013 05:35:09 +0000"  >&lt;p&gt;the same fid would hit -EEXIST at insertion into OI... at least I saw this in development few times.&lt;/p&gt;</comment>
                            <comment id="55966" author="shadow" created="Wed, 10 Apr 2013 06:51:22 +0000"  >&lt;p&gt;Alex, thanks for point - i will ask to look in logs about it, until I worked on patch to waiting a commit on client side, before we may use a sequence - like a synchronous rpc.&lt;br/&gt;
But that is may be valid situation - when both seq allocation and OI update if under RO state and don&apos;t pushed to disk, but client think operation is OK.&lt;/p&gt;</comment>
                            <comment id="55967" author="aboyko" created="Wed, 10 Apr 2013 06:54:25 +0000"  >&lt;p&gt;Xyratex-bug-id: &lt;a href=&quot;http://jira-nss.xy01.xyratex.com:8080/browse/MRP-877&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;MRP-877&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="55968" author="bzzz" created="Wed, 10 Apr 2013 06:56:53 +0000"  >&lt;p&gt;that&apos;s true, with rdonly we can&apos;t ensure a sequence is unique. I do remember there was a discussion on this topic, something about rdonly vs. commit callbacks (which are vital to maintain sequences unique). I&apos;m adding Mike to the conversation..&lt;/p&gt;</comment>
                            <comment id="55971" author="shadow" created="Wed, 10 Apr 2013 08:19:20 +0000"  >&lt;p&gt;quick look - say that is it situation.&lt;br/&gt;
SEQ allocation after r/o set and OI insert likely will be in same time, so ... both lost, but client have a valid inode in cache.&lt;/p&gt;</comment>
                            <comment id="55972" author="bzzz" created="Wed, 10 Apr 2013 08:21:57 +0000"  >&lt;p&gt;iirc, in some tests we did something like file creation at the beginning and before R/O to ensure the sequence has been committed properly.&lt;/p&gt;</comment>
                            <comment id="55974" author="shadow" created="Wed, 10 Apr 2013 09:01:53 +0000"  >&lt;p&gt;and assume creation isn&apos;t blocked and fail always called after it.&lt;/p&gt;

&lt;p&gt;I prepared a prof of concept path, to illustrate my ideas - quick test say it&apos;s worked - but we need to fix much tests to new behavior.&lt;/p&gt;</comment>
                            <comment id="55975" author="bzzz" created="Wed, 10 Apr 2013 09:06:02 +0000"  >&lt;p&gt;creation itself should not block, but sequence allocation MUST wait until it&apos;s committed. IOW, no sequence should be provided if it&apos;s not committed.&lt;br/&gt;
in the current implementation we&apos;re trying to pre-allocate a window of sequences (proportional to the number of clients) and it becomes &quot;available&quot;&lt;br/&gt;
only up on commit callback.&lt;/p&gt;</comment>
                            <comment id="55979" author="shadow" created="Wed, 10 Apr 2013 09:31:01 +0000"  >&lt;p&gt;that is same as i make, but most tests in replay dual have ...&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;test_9() {
    replay_barrier $SINGLEMDS
    mcreate $MOUNT1/$tfile-1
    mcreate $MOUNT2/$tfile-2
    # drop first reint reply
    do_facet $SINGLEMDS lctl set_param fail_loc=0x80000119
    fail $SINGLEMDS
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;so fail $MDS will never called as mcreate blocked on allocation FID sequence.&lt;/p&gt;

&lt;p&gt;same for other tests in replay-dual - until we have free FID&apos;s - it&apos;s works, when need allocate - broke a test.&lt;/p&gt;

&lt;p&gt;some test was have same before.&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;test_0a() {
    touch $MOUNT2/$tfile-A # force sync FLD/SEQ update before barrier
    replay_barrier $SINGLEMDS
#define OBD_FAIL_PTLRPC_FINISH_REPLAY | OBD_FAIL_ONCE
    touch $MOUNT2/$tfile
    createmany -o $MOUNT1/$tfile- 50
    $LCTL set_param fail_loc=0x80000514

..
or
test_4() {
    mkdir $MOUNT1/adir
    replay_barrier $SINGLEMDS
    mkdir $MOUNT1/adir  &amp;amp;&amp;amp; &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; 1
    mkdir $MOUNT2/adir/bdir
    
    fail $SINGLEMDS
    checkstat $MOUNT2/adir      || &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; 2
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;but we have no guaranteed fid will requested on first creation, because depend of previous state.&lt;/p&gt;</comment>
                            <comment id="55981" author="shadow" created="Wed, 10 Apr 2013 09:41:25 +0000"  >&lt;p&gt;prof of concept for fix.&lt;br/&gt;
need have result about test fixes, and restore allocation after replay. Look we need to send same allocation as last client have and resend on client side if that range exhausted.&lt;/p&gt;</comment>
                            <comment id="55982" author="bzzz" created="Wed, 10 Apr 2013 09:49:05 +0000"  >&lt;p&gt;I don&apos;t understand the last comment. I&apos;d think it should be enough to request and commit few sequences in mdt_iocontrol(), just before calling to -&amp;gt;dt_ro()&lt;/p&gt;</comment>
                            <comment id="55984" author="shadow" created="Wed, 10 Apr 2013 10:07:05 +0000"  >&lt;p&gt;how you have send these sequences to the client? and we have no way to think that is enough for client or not.&lt;br/&gt;
and what about power lost before an update on storage?&lt;/p&gt;</comment>
                            <comment id="55985" author="bzzz" created="Wed, 10 Apr 2013 10:09:41 +0000"  >&lt;p&gt;there is no need to send them to the client - the client will request them when needed and get as the sequences have been already allocated and committed.&lt;br/&gt;
power lost before the update implies no commit callback is called and no sequence is available.&lt;/p&gt;</comment>
                            <comment id="55986" author="shadow" created="Wed, 10 Apr 2013 10:20:14 +0000"  >&lt;p&gt;sequences on client side or in server side?&lt;br/&gt;
if you talk about server side - have a good recovery with requests replay will enough to it.&lt;br/&gt;
i that case we don&apos;t need a waiting a commit callback on client - but will be need more work for recovery.&lt;/p&gt;</comment>
                            <comment id="55987" author="bzzz" created="Wed, 10 Apr 2013 10:25:09 +0000"  >&lt;p&gt;strictly speaking it doesn&apos;t matter, both the server and the client should be getting only committed sequences.&lt;br/&gt;
in the context of sequence allocation, it&apos;s commit callback on the server making a sequence available.&lt;/p&gt;</comment>
                            <comment id="55990" author="tappro" created="Wed, 10 Apr 2013 10:52:59 +0000"  >&lt;p&gt;I agree with Alex that this can be just artifact of replay_barrier(). It tries to simulate real behavior of device but it doesn&apos;t that at 100%. Any sync operation will be a problem, because it will finish like non-sync. You can check if your situation is about that. In osd_ro() we can set new flag on osd_device, say od_readonly. Then osd_trans_stop() should check that there is no th_sync and od_readonly toghether and put error message with dump_stack(). Therefore we will know when we have such situation and shouldn&apos;t rely on test results.&lt;/p&gt;</comment>
                            <comment id="55998" author="shadow" created="Wed, 10 Apr 2013 13:18:43 +0000"  >&lt;p&gt;Mike,&lt;/p&gt;

&lt;p&gt;same situation you will have with WB enabled cache for a device, as ldiskfs disable a barrier and some other.&lt;br/&gt;
most async operations is able to replayed except a SEQ request. I think question is incorrect replay for a sequence as that is FS modification request and should be replayed correctly or implemented as sync request to waiting a commits from MDT side.&lt;/p&gt;</comment>
                            <comment id="56003" author="shadow" created="Wed, 10 Apr 2013 13:38:41 +0000"  >&lt;p&gt;btw. it&apos;s not an artifact of replay_barrier as ro/no transno flag used to official way to shutdown target with recovery.&lt;/p&gt;
</comment>
                            <comment id="56004" author="bzzz" created="Wed, 10 Apr 2013 14:01:13 +0000"  >&lt;p&gt;sequence requests are never replayed as sequences are not supposed to be reused. when MDT shuts down it loses its sequences as well and will get new one upon reboot.&lt;br/&gt;
i think you missed the point that when MDS sends a sequence back to the client it (sequence) is already committed to the disk.&lt;/p&gt;</comment>
                            <comment id="56005" author="shadow" created="Wed, 10 Apr 2013 14:39:37 +0000"  >&lt;p&gt;Alex&lt;/p&gt;

&lt;p&gt;1) sync operation only in case...&lt;/p&gt;

&lt;p&gt;                if (seq-&amp;gt;lss_set_transno &amp;gt; dev-&amp;gt;ld_obd-&amp;gt;obd_last_committed)&lt;br/&gt;
                        sync = 1;&lt;br/&gt;
2) notransno and r/o is official way to shutdown target with failover, so we can&apos;t say - that is replay_barrier artifact, we need to make that way work correctly.&lt;/p&gt;

&lt;p&gt;3) as seq allocation need replayed anyway - we may use async transaction so will be speedup for MD operations.&lt;/p&gt;</comment>
                            <comment id="56013" author="tappro" created="Wed, 10 Apr 2013 16:19:14 +0000"  >&lt;p&gt;Alexey,&lt;/p&gt;

&lt;p&gt;could you give an example how r/o (barrier) is used for shutdown officially? What do you mean by that? the replay_barrier has known bugs and it doesn&apos;t work correctly with sync operations, it is real artifact no matter how official the way of using it.&lt;/p&gt;

&lt;p&gt;seq allocaions don&apos;t need replay if the only benefit is speedup. Note that we have pre-created window of many sequences, so in most cases allocation don&apos;t produce sync and doesn&apos;t affect MD operations performance, sync is very rare case, but during tests it may occur more often due to many server failover in recovery tests&lt;/p&gt;</comment>
                            <comment id="56014" author="bzzz" created="Wed, 10 Apr 2013 16:25:22 +0000"  >&lt;p&gt;by the time rdonly is turned on we shouldn&apos;t be handling new requests, so no new sequences are needed while old in-use have been already committed.&lt;/p&gt;</comment>
                            <comment id="56120" author="adilger" created="Thu, 11 Apr 2013 17:52:22 +0000"  >&lt;p&gt;Alex, do we stille use rdonly for shutdown?  I thought that was removed some time ago by Fan Yong.&lt;/p&gt;</comment>
                            <comment id="56121" author="bzzz" created="Thu, 11 Apr 2013 17:55:38 +0000"  >&lt;p&gt;yes, I actually checked the code today and AFAICS we do not use rdonly. even with umount -f.&lt;/p&gt;</comment>
                            <comment id="56830" author="tappro" created="Tue, 23 Apr 2013 17:04:32 +0000"  >&lt;p&gt;Not blocker for 2.4 because happens on old Lustre 2.1 version. The issue is related to sync sequence update during barrier, which can&apos;t handle sync. Current replay_barrier contains workaround to prevent that by creating extra file before barrier which bumps sequence update but that is not so in pre-2.3 Lustre and replay-dual may encounter such conditions. Strictly speaking this is not bug even though may be considered as request for some improvements in test infrastructure to avoid sync updated during replay_barrier() in better way.&lt;/p&gt;</comment>
                            <comment id="56835" author="jlevi" created="Tue, 23 Apr 2013 17:40:52 +0000"  >&lt;p&gt;Dropping priority per Mike&apos;s last comment.&lt;/p&gt;</comment>
                            <comment id="73279" author="shadow" created="Wed, 11 Dec 2013 14:02:27 +0000"  >&lt;p&gt;Finally investigated that issue.&lt;br/&gt;
Regression introduced by &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-220&quot; title=&quot;renaming the cwd of a process on another client exposes some dcache weirdness&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-220&quot;&gt;&lt;del&gt;LU-220&lt;/del&gt;&lt;/a&gt; and MDS_OPEN_BY_FID, and easily replicated with sanity 27B with 2.4 client and 2.1 server.&lt;/p&gt;

&lt;p&gt;2.4 send an &apos;name&apos; as one of parameters of ll_intent_file_open request, but set also an MDS_OPEN_BY_FID flag.&lt;br/&gt;
in script&lt;br/&gt;
create f0, f1;&lt;br/&gt;
open f1&lt;br/&gt;
mv f0 -&amp;gt; f1&lt;br/&gt;
ll_intent_file_open (via ll_file_ioctl) &lt;br/&gt;
....&lt;br/&gt;
close $f1&lt;/p&gt;

&lt;p&gt;in that case open send an request with &apos;f1&apos; name but with fid from older &apos;F1&apos; file, but MDS don&apos;t know about OPEN_BY_FID flag and don&apos;t execute an lookup by fid to find an object in directory. execute an lookup by name &apos;f1&apos; and return a data from older &apos;f0&apos; object, after reply is accepted - client tried to update an older inode from &apos;f1&apos; object with data from a server and client confuses about different FID in answer.&lt;/p&gt;

&lt;p&gt;SO bug in handling an interop in &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-220&quot; title=&quot;renaming the cwd of a process on another client exposes some dcache weirdness&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-220&quot;&gt;&lt;del&gt;LU-220&lt;/del&gt;&lt;/a&gt; patch.&lt;br/&gt;
if it&apos;s need i may attach a full logs from that.&lt;/p&gt;
</comment>
                            <comment id="230715" author="tappro" created="Sun, 22 Jul 2018 09:14:42 +0000"  >&lt;p&gt;outdated issue&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                            <attachment id="12500" name="lelus-134-prof.diff" size="4634" author="shadow" created="Wed, 10 Apr 2013 09:41:25 +0000"/>
                            <attachment id="12499" name="lustre.bin.bz2" size="8444631" author="shadow" created="Wed, 10 Apr 2013 05:17:40 +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|hzvniv:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>7624</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>