<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel">
    <title>gmane.comp.file-systems.ocfs2.devel</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8399"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8398"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8397"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8396"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8395"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8394"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8393"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8392"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8391"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8390"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8389"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8387"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8385"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8384"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8381"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8376"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8375"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8372"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8370"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8368"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8399">
    <title>[PATCH] ocfs2: Free sc-&gt;sc_page in sc_kref_release()v2</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8399</link>
    <description>&lt;pre&gt;There is a memory leak in sc_kref_release().
When free struct o2net_sock_container (sc), 
we should release sc-&amp;gt;sc_page.

Signed-off-by: Younger Liu &amp;lt;younger.liu&amp;lt; at &amp;gt;huawei.com&amp;gt;
Reviewed-by: Jie Liu &amp;lt;jeff.liu&amp;lt; at &amp;gt;oracle.com&amp;gt;
---
 fs/ocfs2/cluster/tcp.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/ocfs2/cluster/tcp.c b/fs/ocfs2/cluster/tcp.c
index aa88bd8..bb9a48b 100644
--- a/fs/ocfs2/cluster/tcp.c
+++ b/fs/ocfs2/cluster/tcp.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -406,6 +406,9 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void sc_kref_release(struct kref *kref)
 sc-&amp;gt;sc_node = NULL;
 
 o2net_debug_del_sc(sc);
+
+if (sc-&amp;gt;sc_page)
+__free_page(sc-&amp;gt;sc_page);
 kfree(sc);
 }
 
&lt;/pre&gt;</description>
    <dc:creator>Younger Liu</dc:creator>
    <dc:date>2013-06-18T06:02:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8398">
    <title>Re: [PATCH] ocfs2: Free sc-&gt;sc_page insc_kref_release()</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8398</link>
    <description>&lt;pre&gt;Thanks for your review comments.
I will resend this patch.

On 2013/6/18 12:35, Jeff Liu wrote:
&lt;/pre&gt;</description>
    <dc:creator>Younger Liu</dc:creator>
    <dc:date>2013-06-18T05:57:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8397">
    <title>Re: [PATCH] ocfs2: Free sc-&gt;sc_page insc_kref_release()</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8397</link>
    <description>&lt;pre&gt;

Nice catch. I have not reacted from another thing in process at that time.

Thanks,
-Jeff

&lt;/pre&gt;</description>
    <dc:creator>Jeff Liu</dc:creator>
    <dc:date>2013-06-18T04:35:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8396">
    <title>Re: [PATCH] ocfs2: Free sc-&gt;sc_page insc_kref_release()</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8396</link>
    <description>&lt;pre&gt;
But why set sc-&amp;gt;sc_page to NULL, given sc is to be kfreed.

&lt;/pre&gt;</description>
    <dc:creator>Li Zefan</dc:creator>
    <dc:date>2013-06-18T04:29:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8395">
    <title>Re: [PATCH] ocfs2: Free sc-&gt;sc_page insc_kref_release()</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8395</link>
    <description>&lt;pre&gt;

Looks fine to me, thanks!

Reviewed-by: Jie Liu &amp;lt;jeff.liu&amp;lt; at &amp;gt;oracle.com&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>Jeff Liu</dc:creator>
    <dc:date>2013-06-18T04:20:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8394">
    <title>[PATCH] ocfs2: Free sc-&gt;sc_page in sc_kref_release()</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8394</link>
    <description>&lt;pre&gt;There is a memory leak in sc_kref_release().
When free struct o2net_sock_container (sc), 
we should release sc-&amp;gt;sc_page.

Signed-off-by: Younger Liu &amp;lt;younger.liu&amp;lt; at &amp;gt;huawei.com&amp;gt;
---
 fs/ocfs2/cluster/tcp.c |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/ocfs2/cluster/tcp.c b/fs/ocfs2/cluster/tcp.c
index aa88bd8..f0272b9 100644
--- a/fs/ocfs2/cluster/tcp.c
+++ b/fs/ocfs2/cluster/tcp.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -406,6 +406,11 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void sc_kref_release(struct kref *kref)
 sc-&amp;gt;sc_node = NULL;
 
 o2net_debug_del_sc(sc);
+
+if (sc-&amp;gt;sc_page) {
+__free_page(sc-&amp;gt;sc_page);
+sc-&amp;gt;sc_page = NULL;
+}
 kfree(sc);
 }
 
&lt;/pre&gt;</description>
    <dc:creator>Younger Liu</dc:creator>
    <dc:date>2013-06-18T03:40:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8393">
    <title>Re: [PATCH] Fix waiting status race condition in dlm recovery V2</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8393</link>
    <description>&lt;pre&gt;
Hi, xiaowei,
We have reviewed this patch and have some questions:
1) in dlm_is_node_in_livemap(), I think it should use 
!!(test_bit(node, dlm-&amp;gt;live_nodes_map)) to determine whether a node is
live;
2) why not use dlm_is_node_dead() instead of dlm_is_node_in_livemap()
in dlm_remaster_locks?
I think dlm_is_node_dead() is better because dlm-&amp;gt;live_nodes_map
may be remain when another node umount.

Thanks.





.
&lt;/pre&gt;</description>
    <dc:creator>Xue jiufei</dc:creator>
    <dc:date>2013-06-18T03:13:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8392">
    <title>Re: [PATCH] unlink performance: wait for open lock in case of dirs</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8392</link>
    <description>&lt;pre&gt;
This is best answered by the DLM. In short, a direct EX grant goes to
the lock master and if no previous lock found, is granted. In the case
of PR-&amp;gt;EX, it first goes to the lock master, the lock master checks
the holders, request each holder to unlock. Once it gets a response
from all PR holders only then grants the lock.


The locking sequence in inode.c:ocfs2_read_locked_inode is open_lock
and then meta locks (ocfs2_inode_lock).
The ocfs2_try_open_lock was a non-blocking sequence and was always
called with meta locks held. However, if we use a blocking open_lock,
it will deadlock. OTOH, if we already posses the PR lock, it means
that the lock sequence already has happened in open_lock-&amp;gt;meta_lock
and hence this is just an upgrade from PR-&amp;gt;EX hence we can wait.


Attached. You will have to modify the name of the other nodes in the
script. In my case, it was "sles11a" and "sles11c". Also remember to
setup .ssh/authorized_keys for automatic logins. You may get delays in
later calls because ocfs2cmt thread wak&lt;/pre&gt;</description>
    <dc:creator>Goldwyn Rodrigues</dc:creator>
    <dc:date>2013-06-18T02:17:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8391">
    <title>Re: [PATCH] unlink performance: wait for open lock in case of dirs</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8391</link>
    <description>&lt;pre&gt;


Why a PR-&amp;gt;EX convert takes longer than a simple EX grant.


why it can avoid the ABBA locking.


Please send the testcase . thanks.

&lt;/pre&gt;</description>
    <dc:creator>shencanquan</dc:creator>
    <dc:date>2013-06-18T01:30:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8390">
    <title>Re: [PATCH] ocfs2: llseek need to inode cluster lock and unlock for update the inode size in SEEK_END.</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8390</link>
    <description>&lt;pre&gt;


I think it maybe impact performance. because it use the cluster lock and
it maybe flush the inode cache to disk and read the inode from disk. but
I think the correct function of llseek is more important.


&lt;/pre&gt;</description>
    <dc:creator>shencanquan</dc:creator>
    <dc:date>2013-06-18T01:03:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8389">
    <title>Re: [PATCH] ocfs2: llseek need to inode cluster lock and unlock for update the inode size in SEEK_END.</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8389</link>
    <description>&lt;pre&gt;

 Thanks for your comments.



yes. it need to protect the offset adjustment.


Thanks you. I will see the document .

&lt;/pre&gt;</description>
    <dc:creator>shencanquan</dc:creator>
    <dc:date>2013-06-18T00:57:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8387">
    <title>Re: [PATCH] ocfs2: llseek need to inode cluster lock and unlock for update the inode size in SEEK_END.</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8387</link>
    <description>&lt;pre&gt;

Can you please wrap these around 72 columns or so in the future?
Also, that would be appreciated if you can supply more detailed
info to reflect the results before/after applying this patch.


Please add spaces between comments and annotation, i.e,
   /*  Need to ...... */


Why not protect the offset adjustment insides ocfs2 inode locks?


Looks your email client has not configured properly for posting patches
because all those changes are not using tab for code indentation, please
refer to Documentation/email-clients.txt for detail if so.

-Jeff
&lt;/pre&gt;</description>
    <dc:creator>Jeff Liu</dc:creator>
    <dc:date>2013-06-17T15:17:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8385">
    <title>Re: [PATCH] Add bits_wanted while calculating credits in ocfs2_calc_extend_credits</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8385</link>
    <description>&lt;pre&gt;

Looks good to me, thank you!
Reviewed-by: Jie Liu &amp;lt;jeff.liu&amp;lt; at &amp;gt;oracle.com&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>Jeff Liu</dc:creator>
    <dc:date>2013-06-17T14:40:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8384">
    <title>[PATCH] Add bits_wanted while calculating credits in ocfs2_calc_extend_credits</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8384</link>
    <description>&lt;pre&gt;While adding extends to a file, the credits are calculated incorrectly
and if the requested clusters is more than one (or more because we used 
a conservative limit) then we run out of journal credits and we hit
an assert in journalling code.

The function parameter bits_wanted variable was not used at all.

Signed-off-by: Goldwyn Rodrigues &amp;lt;rgoldwyn&amp;lt; at &amp;gt;suse.com&amp;gt;

--- 
diff --git a/fs/ocfs2/journal.h b/fs/ocfs2/journal.h
index a3385b6..7d927cd 100644
--- a/fs/ocfs2/journal.h
+++ b/fs/ocfs2/journal.h
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -538,7 +538,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static inline int ocfs2_calc_extend_credits(struct super_block *sb,
 extent_blocks = 1 + 1 + le16_to_cpu(root_el-&amp;gt;l_tree_depth);
 
 return bitmap_blocks + sysfile_bitmap_blocks + extent_blocks +
-       ocfs2_quota_trans_credits(sb);
+       ocfs2_quota_trans_credits(sb) + bits_wanted;
 }
 
 static inline int ocfs2_calc_symlink_credits(struct super_block *sb)
&lt;/pre&gt;</description>
    <dc:creator>Goldwyn Rodrigues</dc:creator>
    <dc:date>2013-06-17T14:08:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8381">
    <title>Re: [PATCH 1/2] ocfs2: Fix llseek() semantics and dosome cleanup</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8381</link>
    <description>&lt;pre&gt;

Hmm??  Did you mean to say that an invalid whence(i.e, whence &amp;gt; SEEK_MAX)
can be passed into generic_file_llseek()?
If so, I don't think that is a problem because any invalid whence should
be rejected at the entrance of VFS lseek(2) with EINVAL.

Thanks,
-Jeff
&lt;/pre&gt;</description>
    <dc:creator>Jeff Liu</dc:creator>
    <dc:date>2013-06-16T07:00:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8376">
    <title>Re: [PATCH 1/2] ocfs2: Fix llseek() semantics and dosome cleanup</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8376</link>
    <description>&lt;pre&gt;[Add ocfs2-devel to CC-list]

Hello Richard,

Thanks for your patch.

On 06/15/2013 03:23 AM, Richard Yao wrote:


Agree, but please see my comments below.


I have another patch set for refactoring ocfs2_file_llseek() but not yet found time
to run a comprehensive tests.  It can solve the existing issues but also improved the
SEEK_DATA/SEEK_HOLE for unwritten extents, i.e. OCFS2_EXT_UNWRITTEN.

With this change, SEEK_DATA/SEEK_HOLE will go into separate function with a little code
duplication instead of the current mix-ups in ocfs2_seek_data_hole_offset(), i.e, 

loff_t ocfs2_file_llseek()
{
switch (origin) {
        case SEEK_END:
        case SEEK_CUR:
        case SEEK_SET:
                return generic_file_llseek(file, offset, origin);
        case SEEK_DATA:
                return ocfs2_seek_data(file, offset);
        case SEEK_HOLE:
                return ocfs2_seek_hole(file, offset);
        default:
                return -EINVAL;
        }
}

I personally like keeping SEEK_DATA/SEEK_HOLE in swi&lt;/pre&gt;</description>
    <dc:creator>Jeff Liu</dc:creator>
    <dc:date>2013-06-15T05:09:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8375">
    <title>[PATCH] unlink performance: wait for open lock incase of dirs</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8375</link>
    <description>&lt;pre&gt;This patch is to improve the unlink performance. Here is the scenario:

On node A, create multiple directories say d1-d8, and each have 3
files under it f1, f2 and f3.
On node B, delete all directories using rm -Rf d*

The FS first unlinks f1, f2 and f3. However, when it performs
ocfs2_evict_inode() -&amp;gt; ocfs2_delete_inode() -&amp;gt;
ocfs2_query_inode_wipe() -&amp;gt; ocfs2_try_open_lock() on d1, it fails
with -EAGAIN. The open lock fails because on the remote node
a PR-&amp;gt;EX convert takes longer than a simple EX grant.

This starts a checkpoint because OCFS2_INODE_DELETED flag is not set
on the directory inode. Now, a checkpoint interferes with the journaling
of the inodes deleted in the following unlinks, in our case,
directories d2-d8 and the files contained in it.

With this patch, We wait on a directory EX lock only if we already
have an open_lock in PR mode. This way we will avoid the ABBA locking.

By waiting for the open_lock on the directory, I am getting a unlink
performance improvement of a rm -Rf of 50-60% in the&lt;/pre&gt;</description>
    <dc:creator>Goldwyn Rodrigues</dc:creator>
    <dc:date>2013-06-15T02:05:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8372">
    <title>Re: unlink: why does try_open_lock fail on directory but works for a file?</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8372</link>
    <description>&lt;pre&gt;     No , I think the directories use the open_lock. because the 
open_lock use to check the other node  had opened the file or directory 
in the ocfs2 cluster. if yes , it can't delete the file or directory on 
the disk.
&lt;/pre&gt;</description>
    <dc:creator>shencanquan</dc:creator>
    <dc:date>2013-06-13T02:03:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8370">
    <title>Re: unlink: why does try_open_lock fail on directory but works for a file?</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8370</link>
    <description>&lt;pre&gt;
This is a self-fabricated test and I just created the directory using
mkdir and files using touch Yes, it is possible that the PR open lock
is still on the directory.


Do you mean to say directories don't use open_lock. Could you provide
the code/design reference?
&lt;/pre&gt;</description>
    <dc:creator>Goldwyn Rodrigues</dc:creator>
    <dc:date>2013-06-10T12:11:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8368">
    <title>Re: unlink: why does try_open_lock fail on directory but works for a file?</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8368</link>
    <description>&lt;pre&gt;  on directory d1 it fail to call ocfs2_try_open_lock, it mean other 
node has lock the open lock. it maybe node A has open the directory d1?
   I don't think that the directory don't use the open_lock, otherwise 
it will be success to call the ocfs2_try_open_lock.
&lt;/pre&gt;</description>
    <dc:creator>shencanquan</dc:creator>
    <dc:date>2013-06-10T10:09:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8367">
    <title>Re: [PATCH v2] ocfs2: fix mutex_unlock and possible memory leak in ocfs2_remove_btree_range</title>
    <link>http://permalink.gmane.org/gmane.comp.file-systems.ocfs2.devel/8367</link>
    <description>&lt;pre&gt;

Reviewed-by: Jie Liu &amp;lt;jeff.liu&amp;lt; at &amp;gt;oracle.com&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>Jeff Liu</dc:creator>
    <dc:date>2013-06-10T08:19:01</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.file-systems.ocfs2.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.file-systems.ocfs2.devel</link>
  </textinput>
</rdf:RDF>
