<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://www.kerneltrap.org"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>KernelTrap - stability</title>
 <link>http://www.kerneltrap.org/taxonomy/term/680/0</link>
 <description></description>
 <language>en-local</language>
<item>
 <title>HAMMER Stabilizing</title>
 <link>http://www.kerneltrap.org/DragonFlyBSD/HAMMER_Stabilizing</link>
 <description>&lt;div class=&quot;taxonomy-images&quot;&gt;&lt;a href=&quot;/news/dragonflybsd&quot; class=&quot;taxonomy-image-links&quot;&gt;&lt;img src=&quot;http://kerneltrap.org/files/category_pictures/K-FlyBSD_1.gif&quot; alt=&quot;DragonFlyBSD&quot; title=&quot;DragonFlyBSD&quot;  width=&quot;75&quot; height=&quot;75&quot; /&gt;&lt;/a&gt;&lt;/div&gt;&lt;!-- google_ad_section_start --&gt;&lt;p&gt;Matthew Dillon sent out a series of &lt;a href=&quot;http://kerneltrap.org/mailarchive/dragonflybsd-kernel/2008/5/12/1798324&quot;&gt;updates&lt;/a&gt; about his developing HAMMER filesystem, noting that he is currently focusing on the reblocking and pruning code, tracking down a number of bugs resulting in B-Tree corruption.  He also noted that previously HAMMER was comprised of three components: B-Tree nodes, records, and data.  In his latest cleanups, he has entirely removed the record structure, &quot;&lt;i&gt;this will seriously improve the performance of directory and inode access.&lt;/i&gt;&quot;  This change did require an on-media &lt;a href=&quot;http://kerneltrap.org/mailarchive/dragonflybsd-kernel/2008/5/12/1801424&quot;&gt;format change&lt;/a&gt;, &quot;&lt;i&gt;I know I have said this before, but there&#039;s a very good chance that no more on-media changes will be made after this point.  The official freeze of the on-media format will not occur until the 2.0 release, however.&lt;/i&gt;&quot;&lt;/p&gt;
&lt;p&gt;Matt &lt;a href=&quot;http://kerneltrap.org/mailarchive/dragonflybsd-kernel/2008/5/11/1790584&quot;&gt;added&lt;/a&gt;, &quot;&lt;i&gt;HAMMER is stable enough now that I am able to run it on my LAN backup box.  I&#039;m using it to test that the snapshots work as expected as well as to test the long term effects of reblocking and pruning.&lt;/i&gt;&quot;  He then cautioned:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;Please note that HAMMER is not ready for production use yet, there is still the filesystem-full handling to implement and much more serious testing of the reblocking and pruning code is required, not to mention the crash recovery code.  I expect to find a few more bugs, but I&#039;m really happy with the results so far.&quot;&lt;/p&gt;&lt;/blockquote&gt;
&lt;!-- google_ad_section_end --&gt;&lt;p&gt;&lt;a href=&quot;http://www.kerneltrap.org/DragonFlyBSD/HAMMER_Stabilizing&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.kerneltrap.org/DragonFlyBSD/HAMMER_Stabilizing#comments</comments>
 <category domain="http://www.kerneltrap.org/DragonFlyBSD">DragonFlyBSD</category>
 <category domain="http://www.kerneltrap.org/filesystem">filesystem</category>
 <category domain="http://www.kerneltrap.org/HAMMER">HAMMER</category>
 <category domain="http://www.kerneltrap.org/Matthew_Dillon">Matthew Dillon</category>
 <category domain="http://www.kerneltrap.org/performance">performance</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/680">stability</category>
 <category domain="http://www.kerneltrap.org/news/dragonflybsd">DragonFlyBSD</category>
 <pubDate>Wed, 14 May 2008 13:11:59 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">16127 at http://www.kerneltrap.org</guid>
</item>
<item>
 <title>Kernel Rate of Change</title>
 <link>http://www.kerneltrap.org/Linux/Kernel_Rate_of_Change</link>
 <description>&lt;div class=&quot;taxonomy-images&quot;&gt;&lt;a href=&quot;/news/linux&quot; class=&quot;taxonomy-image-links&quot;&gt;&lt;img src=&quot;http://kerneltrap.org/files/category_pictures/K-Linux.gif&quot; alt=&quot;Linux news&quot; title=&quot;Linux news&quot;  width=&quot;75&quot; height=&quot;75&quot; /&gt;&lt;/a&gt;&lt;/div&gt;&lt;!-- google_ad_section_start --&gt;&lt;p&gt;&quot;&lt;i&gt;I re-ran some statistics the other day on our kernel development rate, and changed my formula after Andrew accused me of severely undercounting the rate of change,&lt;/i&gt;&quot; &lt;a href=&quot;http://kerneltrap.org/mailarchive/linux-kernel/2008/2/2/700024&quot;&gt;noted Greg KH&lt;/a&gt; during a discussion about the stability of the Linux kernel while undergoing significant changes.  He continued, &quot;&lt;i&gt;turns out that as of 2.6.24-rc8 for the 2.6.24 kernel release we did: lines added per day, 4945; lines removed per day, 2006; lines modified per day,	1702&lt;/i&gt;&quot;.  Greg added:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;And note, that is real stuff, not renames or file moves at all, git handles not reporting that.  That&#039;s for the 99 days that it took to do 2.6.24-rc8 (I need to re-run the scripts now that 2.6.24 is out.)  It&#039;s fricken scarily amazing that things are still working at all...  Just something to make you all sleep well at night :)&quot;&lt;/p&gt;&lt;/blockquote&gt;
&lt;!-- google_ad_section_end --&gt;&lt;p&gt;&lt;a href=&quot;http://www.kerneltrap.org/Linux/Kernel_Rate_of_Change&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.kerneltrap.org/Linux/Kernel_Rate_of_Change#comments</comments>
 <category domain="http://www.kerneltrap.org/development_process">development process</category>
 <category domain="http://www.kerneltrap.org/Greg_KH">Greg KH</category>
 <category domain="http://www.kerneltrap.org/Linux">Linux</category>
 <category domain="http://www.kerneltrap.org/merge_window">merge window</category>
 <category domain="http://www.kerneltrap.org/taxonomy/term/680">stability</category>
 <category domain="http://www.kerneltrap.org/news/linux">Linux news</category>
 <pubDate>Sun, 03 Feb 2008 08:11:44 +0000</pubDate>
 <dc:creator>Jeremy</dc:creator>
 <guid isPermaLink="false">15402 at http://www.kerneltrap.org</guid>
</item>
<item>
 <title>ZFS Stability</title>
 <link>http://www.kerneltrap.org/FreeBSD/ZFS_Stability</link>
 <description>&lt;div class=&quot;taxonomy-images&quot;&gt;&lt;a href=&quot;/news/freebsd&quot; class=&quot;taxonomy-image-links&quot;&gt;&lt;img src=&quot;http://kt1.osuosl.org/files/category_pictures/K-FreeBSD_0.gif&quot; alt=&quot;FreeBSD news&quot; title=&quot;FreeBSD news&quot;  width=&quot;75&quot; height=&quot;75&quot; /&gt;&lt;/a&gt;&lt;/div&gt;&lt;!-- google_ad_section_start --&gt;&lt;p&gt;A recent thread on the FreeBSD -current mailing list discussed the stability of ZFS on FreeBSD.  &lt;a href=&quot;http://kerneltrap.org/mailarchive/freebsd-current/2008/1/6/543152&quot;&gt;Scott Long noted&lt;/a&gt; that ZFS requires proper tuning to be stable:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;I guess what makes me mad about ZFS is that it&#039;s all-or-nothing; either it works, or it crashes.  It doesn&#039;t automatically recognize limits and make adjustments or sacrifices when it reaches those limits, it just crashes.  Wanting multiple gigabytes of RAM for caching in order to optimize performance is great, but crashing when it doesn&#039;t get those multiple gigabytes of RAM is not so great, and it leaves a bad taste in my mouth about ZFS in general.&quot;&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;ZFS was committed in April of 2007 by Pawel Dawidek &lt;a href=&quot;http://kerneltrap.org/mailarchive/freebsd-current/2008/1/7/544178&quot;&gt;who notes&lt;/a&gt; that he is using ZFS quite successfully on all of his systems.   He then cautioned, &quot;&lt;i&gt;of course all this doesn&#039;t mean ZFS works great on FreeBSD. No. It is still an experimental feature.&lt;/i&gt;&quot;  In response to some negative comments about ZFS on FreeBSD, Pawel noted, &quot;&lt;i&gt;in my opinion people are panicing in this thread much more than ZFS:)  Let try to think how we can warn people clearly about proper tunning and what proper tunning actually means. I think we should advise increasing KVA_PAGES on i386 and not only vm.kmem_