<?xml version="1.0" encoding="UTF-8"?><!-- generator="b2evolution/0.9.1" -->
<rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"					xmlns:admin="http://webns.net/mvcb/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel rdf:about="http://b2e.portonvictor.org/index.php">
<title>All Porton's Blog Messages - Last comments</title>
<link>http://b2e.portonvictor.org/index.php?disp=comments</link>
<description></description>
<dc:language>en-EU</dc:language>
<admin:generatorAgent rdf:resource="http://b2evolution.net/?v=0.9.1"/>
<sy:updatePeriod>hourly</sy:updatePeriod>
<sy:updateFrequency>1</sy:updateFrequency>
<sy:updateBase>2000-01-01T12:00+00:00</sy:updateBase>
<items>
<rdf:Seq>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/christian/2006/04/05/i_cannot_preach_gospel_anymore#c6384"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2006/03/03/b2evolution_0_9_1_bug_with_xml_rpc#c3993"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/porton/2005/08/17/blog_for_mary#c3961"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2005/09/11/b2e_google_sitemap_preliminary_release#c3831"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2006/03/04/google_sitemap_for_b2evolution_0_5#c3696"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2006/03/04/google_sitemap_for_b2evolution_0_5#c3530"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2006/03/03/b2evolution_0_9_1_bug_with_xml_rpc#c3529"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2006/03/04/google_sitemap_for_b2evolution_0_5#c3527"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3523"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2005/09/11/b2e_google_sitemap_preliminary_release#c3522"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/test/2006/03/02/b2evo_0_9_1_test_international_xml_rpc#c3521"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2006/02/28/i_have_upgraded_b2evolution_to_0_9_1#c3519"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3438"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3435"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3434"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3433"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3432"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3431"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/soft/2006/02/03/hypertext_labbrgdoml_abbrg_browser_1_0_2_1#c3375"/>
<rdf:li rdf:resource="http://b2e.portonvictor.org/index.php/porton/2006/02/13/mainboard_noise_asrock_pvm800_pm800#c3295"/>
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://b2e.portonvictor.org/index.php/christian/2006/04/05/i_cannot_preach_gospel_anymore#c6384">
<title>In response to: I cannot preach Gospel anymore</title>
<link>http://b2e.portonvictor.org/index.php/christian/2006/04/05/i_cannot_preach_gospel_anymore#c6384</link>
<dc:date>2006-05-03T17:01:47Z</dc:date>
<dc:creator>Diane [Visitor]</dc:creator>
<description>What?

I think a little clarification is necessary.

:)  Diane</description>
<content:encoded><![CDATA[What?  <br />
<br />
I think a little clarification is necessary.  <br />
<br />
:)  Diane]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2006/03/03/b2evolution_0_9_1_bug_with_xml_rpc#c3993">
<title>In response to: b2evolution 0.9.1 - a bug with XML RPC</title>
<link>http://b2e.portonvictor.org/index.php/soft/2006/03/03/b2evolution_0_9_1_bug_with_xml_rpc#c3993</link>
<dc:date>2006-04-04T15:43:58Z</dc:date>
<dc:creator>Helen, software developer [Visitor]</dc:creator>
<description>I think the fact that the bug is specific for the cases when the posted messages contain international characters may be true. </description>
<content:encoded><![CDATA[I think the fact that the bug is specific for the cases when the posted messages contain international characters may be true. ]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/porton/2005/08/17/blog_for_mary#c3961">
<title>In response to: Blog reserved for my wife, Mary</title>
<link>http://b2e.portonvictor.org/index.php/porton/2005/08/17/blog_for_mary#c3961</link>
<dc:date>2006-03-24T17:07:12Z</dc:date>
<dc:creator>Victor [Member]</dc:creator>
<description>Well, I've forgot this password even myself.

So Mary may also not type it.</description>
<content:encoded><![CDATA[Well, I've forgot this password even myself.<br />
<br />
So Mary may also not type it.]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2005/09/11/b2e_google_sitemap_preliminary_release#c3831">
<title>In response to: Google Sitemap for b2evolution (new, advanced)</title>
<link>http://b2e.portonvictor.org/index.php/soft/2005/09/11/b2e_google_sitemap_preliminary_release#c3831</link>
<dc:date>2006-03-23T23:28:47Z</dc:date>
<dc:creator>Michael [Visitor]</dc:creator>
<description>Having trouble with your sitemap script. Installed as instructed.

Google sitemaps reports this error says "Unsupported file format"

any advice </description>
<content:encoded><![CDATA[Having trouble with your sitemap script. Installed as instructed.

Google sitemaps reports this error says "Unsupported file format"

any advice ]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2006/03/04/google_sitemap_for_b2evolution_0_5#c3696">
<title>In response to: Google Sitemap for b2evolution version 0.5</title>
<link>http://b2e.portonvictor.org/index.php/soft/2006/03/04/google_sitemap_for_b2evolution_0_5#c3696</link>
<dc:date>2006-03-21T03:57:15Z</dc:date>
<dc:creator>David [Visitor]</dc:creator>
<description>I have installed this plugin on my site and I get the following error from my google account:

Error  Detail
Nested Indexing  This URL refers to a Sitemap Index, not a Sitemap. Please remove it and resubmit. More
Nested Indexing  This URL refers to a Sitemap Index, not a Sitemap. Please remove it and resubmit. More
Invalid URL (Line 5) in Sitemap http://www.zimorama.com/google-sitemap-archives.php  This is not a valid URL. Please correct it and resubmit. More
Invalid tag value (Line 6) in Sitemap http://www.zimorama.com/google-sitemap-feeds.php?postsfeed=1&#38;commentsfeed=1

what have I done wrong?</description>
<content:encoded><![CDATA[I have installed this plugin on my site and I get the following error from my google account:<br />
<br />
Error  Detail  <br />
Nested Indexing  This URL refers to a Sitemap Index, not a Sitemap. Please remove it and resubmit. More  <br />
Nested Indexing  This URL refers to a Sitemap Index, not a Sitemap. Please remove it and resubmit. More  <br />
Invalid URL (Line 5) in Sitemap http://www.zimorama.com/google-sitemap-archives.php  This is not a valid URL. Please correct it and resubmit. More  <br />
Invalid tag value (Line 6) in Sitemap http://www.zimorama.com/google-sitemap-feeds.php?postsfeed=1&amp;commentsfeed=1  <br />
<br />
what have I done wrong?]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2006/03/04/google_sitemap_for_b2evolution_0_5#c3530">
<title>In response to: Google Sitemap for b2evolution version 0.5</title>
<link>http://b2e.portonvictor.org/index.php/soft/2006/03/04/google_sitemap_for_b2evolution_0_5#c3530</link>
<dc:date>2006-03-07T11:49:03Z</dc:date>
<dc:creator>JC John SESE Cuneta [Visitor]</dc:creator>
<description>Well, using RSS and Atom feeds for Google Sitemap is still less effective than using Google Sitemap directly.
I'm not sure about it but that's what I noticed with the other sites where I'm using Google Sitemaps vs using RSS/Atom for gSitemaps.

</description>
<content:encoded><![CDATA[Well, using RSS and Atom feeds for Google Sitemap is still less effective than using Google Sitemap directly.<br />
I'm not sure about it but that's what I noticed with the other sites where I'm using Google Sitemaps vs using RSS/Atom for gSitemaps.<br />
<br />
]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2006/03/03/b2evolution_0_9_1_bug_with_xml_rpc#c3529">
<title>In response to: b2evolution 0.9.1 - a bug with XML RPC</title>
<link>http://b2e.portonvictor.org/index.php/soft/2006/03/03/b2evolution_0_9_1_bug_with_xml_rpc#c3529</link>
<dc:date>2006-03-07T11:45:59Z</dc:date>
<dc:creator>JC John SESE Cuneta [Visitor]</dc:creator>
<description>ah, so I'm not alone..
I think it goes far beyond that, in my b2e blog, I am using a different charset, en-PH / en-PH-utf8.

I noticed that b2e isn't pinging Technorati and weblogs.

Probably it has something to do with the charset, I'm not sure, but I did noticed something's wrong.

Haven't tried setting my charset to a different one though, it was only after I read your post that I got an idea as to what could be the problem.

</description>
<content:encoded><![CDATA[ah, so I'm not alone..<br />
I think it goes far beyond that, in my b2e blog, I am using a different charset, en-PH / en-PH-utf8.<br />
<br />
I noticed that b2e isn't pinging Technorati and weblogs.<br />
<br />
Probably it has something to do with the charset, I'm not sure, but I did noticed something's wrong.<br />
<br />
Haven't tried setting my charset to a different one though, it was only after I read your post that I got an idea as to what could be the problem.<br />
<br />
]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2006/03/04/google_sitemap_for_b2evolution_0_5#c3527">
<title>In response to: Google Sitemap for b2evolution version 0.5</title>
<link>http://b2e.portonvictor.org/index.php/soft/2006/03/04/google_sitemap_for_b2evolution_0_5#c3527</link>
<dc:date>2006-03-06T17:39:55Z</dc:date>
<dc:creator>Jeremy Bettis [Visitor]</dc:creator>
<description>But why? Google can already use RSS and Atom feeds as a sitemap.</description>
<content:encoded><![CDATA[But why? Google can already use RSS and Atom feeds as a sitemap.]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3523">
<title>In response to: Linux performance bug - zero links fsync()</title>
<link>http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3523</link>
<dc:date>2006-03-04T15:46:06Z</dc:date>
<dc:creator>Theodore Tso [Visitor]</dc:creator>
<description>Can you name real-life examples of programs that stupidly call fsync() on an unlinked file descriptor?   Even in the case of a library which doesn't know better, I still can't think of a real-life library which would do so.  Most of the time real-life code calls fsync() because they have a very specific, real-world reason why they feel they need to do so.

In fact, I just did a "nm -Dou /usr/lib/*.so | grep fsync", and (a) there aren't that many, and (b) I could pretty much identify why all of them would be calling fsync(), and none of them do it randomly or friviously on a file descriptor just for yuks, or would be likely in a real world to be calling fsync() on a file descriptor for a tmp file that has been unlinked.

In general, calling fsync() for no reason is stupid, since it trashes your performance, linked or unlinked file.  So usually it is done only in special circumstances or in libraries, by direct request by the calling application when it has a very good reason to do so.

That's not to say that your recommendation to unlink tmp files isn't a good idea.  It is a good idea, and it's also not old news.  Most applications that need temp files will indeed unlink and keep a file descriptor to it, but they do so just so they don't have to worry about cleaning up the file and deleting it in case the program dies or is killed in the middle of its operation.

But calling this a major performance bug, when in fact it only shows up in contrived test programs, and not in real life, seems to be stretching things immensely.</description>
<content:encoded><![CDATA[Can you name real-life examples of programs that stupidly call fsync() on an unlinked file descriptor?   Even in the case of a library which doesn't know better, I still can't think of a real-life library which would do so.  Most of the time real-life code calls fsync() because they have a very specific, real-world reason why they feel they need to do so.  <br />
<br />
In fact, I just did a "nm -Dou /usr/lib/*.so | grep fsync", and (a) there aren't that many, and (b) I could pretty much identify why all of them would be calling fsync(), and none of them do it randomly or friviously on a file descriptor just for yuks, or would be likely in a real world to be calling fsync() on a file descriptor for a tmp file that has been unlinked.<br />
<br />
In general, calling fsync() for no reason is stupid, since it trashes your performance, linked or unlinked file.  So usually it is done only in special circumstances or in libraries, by direct request by the calling application when it has a very good reason to do so.<br />
<br />
That's not to say that your recommendation to unlink tmp files isn't a good idea.  It is a good idea, and it's also not old news.  Most applications that need temp files will indeed unlink and keep a file descriptor to it, but they do so just so they don't have to worry about cleaning up the file and deleting it in case the program dies or is killed in the middle of its operation.<br />
<br />
But calling this a major performance bug, when in fact it only shows up in contrived test programs, and not in real life, seems to be stretching things immensely.]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2005/09/11/b2e_google_sitemap_preliminary_release#c3522">
<title>In response to: Google Sitemap for b2evolution (new, advanced)</title>
<link>http://b2e.portonvictor.org/index.php/soft/2005/09/11/b2e_google_sitemap_preliminary_release#c3522</link>
<dc:date>2006-03-04T03:59:49Z</dc:date>
<dc:creator>Victor [Member]</dc:creator>
<description>Use the GNU patch utility. Search Web for "GNU patch". On Windows it is often called patch.exe. (However not every patch.exe will work. You need namely GNU version of patch.)</description>
<content:encoded><![CDATA[Use the GNU patch utility. Search Web for "GNU patch". On Windows it is often called <code>patch.exe</code>. (However not every <code>patch.exe</code> will work. You need namely <strong>GNU</strong> version of patch.)]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/test/2006/03/02/b2evo_0_9_1_test_international_xml_rpc#c3521">
<title>In response to: Тестирование b2evolution 0.9.1 - интернациональные XML RPC</title>
<link>http://b2e.portonvictor.org/index.php/test/2006/03/02/b2evo_0_9_1_test_international_xml_rpc#c3521</link>
<dc:date>2006-03-02T20:07:33Z</dc:date>
<dc:creator>Victor [Member]</dc:creator>
<description>Как ни странно, тест успешно пройден, несмотря на то, что раньше была ошибка.

Я сейчас не понимаю в чем дело.</description>
<content:encoded><![CDATA[Как ни странно, тест успешно пройден, несмотря на то, что раньше была ошибка.<br />
<br />
Я сейчас не понимаю в чем дело.]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2006/02/28/i_have_upgraded_b2evolution_to_0_9_1#c3519">
<title>In response to: I have upgraded b2evolution to 0.9.1</title>
<link>http://b2e.portonvictor.org/index.php/soft/2006/02/28/i_have_upgraded_b2evolution_to_0_9_1#c3519</link>
<dc:date>2006-03-01T18:30:54Z</dc:date>
<dc:creator>Victor [Member]</dc:creator>
<description>OK, I have successfully installed b2evolution 0.9.1.

I have configured and tested it. Now it works.</description>
<content:encoded><![CDATA[OK, I have successfully installed b2evolution 0.9.1.<br />
<br />
I have configured and tested it. Now it works.]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3438">
<title>In response to: Linux performance bug - zero links fsync()</title>
<link>http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3438</link>
<dc:date>2006-03-01T09:23:41Z</dc:date>
<dc:creator>Victor [Member]</dc:creator>
<description>I could add a summation of the thoughts in this page as an official comment to the POSIX standard!

Otherwise, it is too easy for an OS developer to skip (forget, not guess) about this little but important for OS performance optimization.

It was not even in Linux about which all the World cares till 2006 year. It is a simple idea but hard to guess and not skip.</description>
<content:encoded><![CDATA[I could add a summation of the thoughts in this page as an official comment to the <abbr>POSIX</abbr> standard!<br />
<br />
Otherwise, it is too easy for an <abbr>OS</abbr> developer to skip (forget, not guess) about this little but important for <abbr>OS</abbr> performance optimization.<br />
<br />
It was not even in Linux about which all the World cares till 2006 year. It is a simple idea but hard to guess and not skip.]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3435">
<title>In response to: Linux performance bug - zero links fsync()</title>
<link>http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3435</link>
<dc:date>2006-03-01T00:30:25Z</dc:date>
<dc:creator>Victor [Member]</dc:creator>
<description>Some keywords for this topic:

disk performance test, disk I/O performance test, disk input/output performance test, HDD performance test, HDD I/O performance test, HDD input/output performance test,
disk speed test, disk I/O speed test, disk input/output speed test, OS performance test, operating system performance test.</description>
<content:encoded><![CDATA[Some keywords for this topic:

<strong>disk performance test</strong>, <strong>disk I/O performance test</strong>, <strong>disk input/output performance test</strong>, <strong>HDD performance test</strong>, <strong>HDD I/O performance test</strong>, <strong>HDD input/output performance test</strong>,
<strong>disk speed test</strong>, <strong>disk I/O speed test</strong>, <strong>disk input/output speed test</strong>, <strong>OS performance test</strong>, <strong>operating system performance test</strong>.]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3434">
<title>In response to: Linux performance bug - zero links fsync()</title>
<link>http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3434</link>
<dc:date>2006-03-01T00:25:08Z</dc:date>
<dc:creator>Victor [Member]</dc:creator>
<description>BTW, this applies to any POSIX compliant OS not just to Linux.

Check other OSes (FreeBSD, Solaris, as well as all Unixes, etc.) to pass this test without unnecessary disk loading.</description>
<content:encoded><![CDATA[<abbr title="By the way">BTW</abbr>, this applies to any <abbr>POSIX</abbr> compliant <abbr>OS</abbr> not just to Linux.<br />
<br />
Check other <abbr>OS</abbr>es (<acronym>FreeBSD</acronym>, Solaris, as well as all Unixes, etc.) to pass this test without unnecessary disk loading.]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3433">
<title>In response to: Linux performance bug - zero links fsync()</title>
<link>http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3433</link>
<dc:date>2006-02-28T23:57:47Z</dc:date>
<dc:creator>Victor [Member]</dc:creator>
<description>Well, actually in any reasonable OS (I'm not sure about real implementation in Linux), fsync() would be implemented like this:

int fsync(int fd)
{
fdatasync(fd);
fsyncmetadata();
return ...;
} or:
int fsync(int fd)
{
fsyncmetadata();
fdatasync(fd);
return ...;
}
(for simplicity return values are skipped)
where fsyncmetadata() is a hypothetical function which would do the rest of the job of fsync() except of what fdatasync() does.

With this note the above complex algorithm scheme could be simplified:

fdatasync() should proceed as usual for files with more than zero links.
fdatasync() should do nothing for files with zero links.
fsync() should be implemented as usual through calling fdatasync()


This will sync file metadata when needed and never sync file data (content) for files with zero links. This exactly what we need.</description>
<content:encoded><![CDATA[Well, actually in any reasonable <abbr title="operating system">OS</abbr> (I'm not sure about real implementation in Linux), <code>fsync()</code> would be implemented like this:

<pre>int fsync(int fd)
{
fdatasync(fd);
fsyncmetadata();
return ...;
}</pre> or:
<pre>int fsync(int fd)
{
fsyncmetadata();
fdatasync(fd);
return ...;
}</pre>
(for simplicity return values are skipped)
where <code>fsyncmetadata()</code> is a hypothetical function which would do the rest of the job of <code>fsync()</code> except of what <code>fdatasync()</code> does.

With this note the above complex algorithm scheme could be simplified:
<ul>
<li><code>fdatasync()</code> should proceed as usual for files with more than zero links.</li>
<li><code>fdatasync()</code> should do nothing for files with zero links.</li>
<li><code>fsync()</code> should be implemented as usual through calling <code>fdatasync()</code></li>
</ul>

This will sync file metadata when needed and never sync file data (content) for files with zero links. This exactly what we need.]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3432">
<title>In response to: Linux performance bug - zero links fsync()</title>
<link>http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3432</link>
<dc:date>2006-02-28T23:42:46Z</dc:date>
<dc:creator>Victor [Member]</dc:creator>
<description>Well, kernel hackers who will implement my idea, also remember that my idea should be implemented not only for external (user visible) syscalls fsync() and fdatasync() but also for all similar kernel internals which accomplish data synchronization:


implementation of sync();
implementation of loop devices attached to disk files;
etc.


When you will implement it in Linux kernel, please leave here a note telling the kernel version where you have implemented it.</description>
<content:encoded><![CDATA[Well, kernel hackers who will implement my idea, also remember that my idea should be implemented not only for external (user visible) syscalls <code>fsync()</code> and <code>fdatasync()</code> but also for all similar kernel internals which accomplish data synchronization:

<ul>
<li>implementation of <code>sync()</code>;</li>
<li>implementation of loop devices attached to disk files;</li>
<li>etc.</li>
</ul>

When you will implement it in Linux kernel, please leave here a note telling the kernel version where you have implemented it.]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3431">
<title>In response to: Linux performance bug - zero links fsync()</title>
<link>http://b2e.portonvictor.org/index.php/soft/2006/02/24/linux_performance_bug_zero_links_fsync#c3431</link>
<dc:date>2006-02-28T23:16:38Z</dc:date>
<dc:creator>Victor [Member]</dc:creator>
<description>I have communicated this my idea in mailing lists. Stephen C. Tweedie from RedHat has noted a mistake (a wrong change of semantics) in my idea:


Correct.  And the semantics *will* change with this patch, but in a
subtle way.

Ext3 happens to guarantee that after fsync(), *all* metadata for a file
--- including directory metadata --- are synchronized to disk.  So if
you unlink an open file and then fsync() it, you are guaranteed that the
unlink has been committed to disk.  This is not, strictly speaking, a
behavior required by POSIX; but it's still useful, and would be broken
if we disabled fsync() for files with i_nlink==0.


Below is my response to his note where I correct the above to eliminate this mistake:

OK, Stephen, you has pointed where following my idea would really
significantly change the semantics, and it should not do.

So fsync() (but not fdatasync()) should indeed have effect on an inode with
zero links but _only the first time_. Precisely:

1. With every fd should be associated a boolean flag "no_links_committed"
(to save a bit of memory it could be instead implemented e.g. as having -1
(minus one) as the count of links in the fd data structure instead of 0).

2. When a file is unlinked, then if the number of links becomes zero
no_links_commited should be in reset state (or write zero as the count of
links in the fd data structure).

3. When fsync() (but not fdatasync() which is simpler) is called on a file:
- If the number of links is above 0 proceed as usual.
- If the number of links is zero:
* If no_links_commited is false do directory synchronization
(as mentioned by Stephen) but no other synchronization and
then set no_links_committed to true (or number of links to -1 for
a little more efficient impl.)
* If no_links_committed is true, do nothing.


So my corrected suggestions for a change of Linux kernel is:


fdatasync() should have no effect on files with zero links (nor on files with -1 links, see below).
fd (file descriptor) or inode data structure which contains the number of links of a file should allow additional value -1 (minus one) as the number of links.
When a file with one link is unlinked, proceed as usual (decrease the number of links to zero).
When fsync() is called on a file with this count of links equal to there, then:

accomplish synchronization to the disk of the directories which was containing this file (from which this file was removed), but not of the file itself;
decrement the count of links of this fd so making it equal -1.


When fsync() is called on a fd with -1 links, do nothing. (There are no need to synchronize this inode to disk as it is not a real use visible file, and directories from which it was removed are already synchronized.)


So somebody make a patch for Linux kernel. It will be a significant speedup.</description>
<content:encoded><![CDATA[I have communicated this my idea in mailing lists. Stephen C. Tweedie from RedHat has noted a mistake (a wrong change of semantics) in my idea:

<blockquote>
Correct.  And the semantics *will* change with this patch, but in a
subtle way.

Ext3 happens to guarantee that after fsync(), *all* metadata for a file
--- including directory metadata --- are synchronized to disk.  So if
you unlink an open file and then fsync() it, you are guaranteed that the
unlink has been committed to disk.  This is not, strictly speaking, a
behavior required by POSIX; but it's still useful, and would be broken
if we disabled fsync() for files with i_nlink==0.
</blockquote>

Below is my response to his note where I correct the above to eliminate this mistake:

<pre>OK, Stephen, you has pointed where following my idea would really
significantly change the semantics, and it should not do.

So fsync() (but not fdatasync()) should indeed have effect on an inode with
zero links but _only the first time_. Precisely:

1. With every fd should be associated a boolean flag "no_links_committed"
(to save a bit of memory it could be instead implemented e.g. as having -1
(minus one) as the count of links in the fd data structure instead of 0).

2. When a file is unlinked, then if the number of links becomes zero
no_links_commited should be in reset state (or write zero as the count of
links in the fd data structure).

3. When fsync() (but not fdatasync() which is simpler) is called on a file:
- If the number of links is above 0 proceed as usual.
- If the number of links is zero:
* If no_links_commited is false do directory synchronization
(as mentioned by Stephen) but no other synchronization and
then set no_links_committed to true (or number of links to -1 for
a little more efficient impl.)
* If no_links_committed is true, do nothing.
</pre>

So my corrected suggestions for a change of Linux kernel is:

<ul>
<li><code>fdatasync()</code> should have no effect on files with zero links (nor on files with -1 links, see below).</li>
<li>fd (file descriptor) or inode data structure which contains the number of links of a file should allow additional value -1 (minus one) as the number of links.</li>
<li>When a file with one link is unlinked, proceed as usual (decrease the number of links to zero).</li>
<li>When <code>fsync()</code> is called on a file with this count of links equal to there, then:
<ol>
<li>accomplish synchronization to the disk of the directories which was containing this file (from which this file was removed), but not of the file itself;</li>
<li>decrement the count of links of this fd so making it equal -1.</li>
</ol>
</li>
<li>When <code>fsync()</code> is called on a fd with -1 links, do nothing. (There are no need to synchronize this inode to disk as it is not a real use visible file, and directories from which it was removed are already synchronized.)</li>
</ul>

So somebody make a patch for Linux kernel. It will be a significant speedup.]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/soft/2006/02/03/hypertext_labbrgdoml_abbrg_browser_1_0_2_1#c3375">
<title>In response to: Hypertext DOM Browser 1.0.2.1</title>
<link>http://b2e.portonvictor.org/index.php/soft/2006/02/03/hypertext_labbrgdoml_abbrg_browser_1_0_2_1#c3375</link>
<dc:date>2006-02-22T15:31:18Z</dc:date>
<dc:creator>VitRom [Visitor]</dc:creator>
<description>FALSE!

from ex-code.com/dom-brouser page:
Hypertext DOM Browser
Download (version 1.0.2)

NOT 1.0.2.1!
AND donload link points to online-dom-brouser.xpi file that contain files dated with 30-dec-05</description>
<content:encoded><![CDATA[FALSE!<br />
<br />
from ex-code.com/dom-brouser page:<br />
Hypertext DOM Browser<br />
Download (version 1.0.2)<br />
<br />
NOT 1.0.2.1!<br />
AND donload link points to online-dom-brouser.xpi file that contain files dated with 30-dec-05]]></content:encoded>
</item>
<item rdf:about="http://b2e.portonvictor.org/index.php/porton/2006/02/13/mainboard_noise_asrock_pvm800_pm800#c3295">
<title>In response to: Mainboard ASRock PVM800/M/ASR produces noise?</title>
<link>http://b2e.portonvictor.org/index.php/porton/2006/02/13/mainboard_noise_asrock_pvm800_pm800#c3295</link>
<dc:date>2006-02-13T13:55:25Z</dc:date>
<dc:creator>Victor [Member]</dc:creator>
<description>I've forgot to say that I have configured VIA's framebuffer driver to 85 Hz and hardware graphics acceleration.</description>
<content:encoded><![CDATA[I've forgot to say that I have configured <abbr>VIA</abbr>'s framebuffer driver to 85 Hz and hardware graphics acceleration.]]></content:encoded>
</item>
</rdf:RDF>

