<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: Ways to use up RAM	</title>
	<atom:link href="https://www.dragonflydigest.com/2003/09/24/ways-to-use-up-ram/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.dragonflydigest.com/2003/09/24/ways-to-use-up-ram/</link>
	<description>A running description of activity related to DragonFly BSD.</description>
	<lastBuildDate>Tue, 30 Sep 2003 22:12:38 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1</generator>
	<item>
		<title>
		By: Robert Clark		</title>
		<link>https://www.dragonflydigest.com/2003/09/24/ways-to-use-up-ram/comment-page-1/#comment-12</link>

		<dc:creator><![CDATA[Robert Clark]]></dc:creator>
		<pubDate>Tue, 30 Sep 2003 22:12:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.shiningsilence.com/dbsdlog/?p=32#comment-12</guid>

					<description><![CDATA[I&#039;d like to be able to overlay a compact flash filesystem, over a hard disk filesystem, over a CDROM filesystem.

That way the system can be booted from CDROM, modified or speed critical data can be copied to HD, and if CF is available then the HD can be spundown until the CF gets full.

Backup just becomes a matter of preparing a new ISO, burning it, and swapping the new and active copies.

If CDROM is too restraining, then move to DVDROM.
]]></description>
			<content:encoded><![CDATA[<p>I&#8217;d like to be able to overlay a compact flash filesystem, over a hard disk filesystem, over a CDROM filesystem.</p>
<p>That way the system can be booted from CDROM, modified or speed critical data can be copied to HD, and if CF is available then the HD can be spundown until the CF gets full.</p>
<p>Backup just becomes a matter of preparing a new ISO, burning it, and swapping the new and active copies.</p>
<p>If CDROM is too restraining, then move to DVDROM.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Justin C. Sherrill		</title>
		<link>https://www.dragonflydigest.com/2003/09/24/ways-to-use-up-ram/comment-page-1/#comment-11</link>

		<dc:creator><![CDATA[Justin C. Sherrill]]></dc:creator>
		<pubDate>Thu, 25 Sep 2003 15:22:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.shiningsilence.com/dbsdlog/?p=32#comment-11</guid>

					<description><![CDATA[I was thinking a RAM-based snapshot would let you cache data in RAM, with the only speed hit when memory is initially accessed.  Data would then be flushed to disk on an occasional basis.

You&#039;d only get a speed benefit when accessing data that had been recently touched, though.  Good for, say, a news server, and maybe a mail server, to some extent.  It&#039;s only a half-formed idea, in any case, and it can wait until the rest of the system is developed.

I have had a recurring geek fantasy of acquiring a motherboard with many gigabytes of RAM, and using that for /usr/obj/, /tmp, and perhaps /usr/ports/, just storing/refreshing it on shutdown/boot.  It&#039;s not terribly practical now, but maybe if RAM keeps doing the eternal price slide...]]></description>
			<content:encoded><![CDATA[<p>I was thinking a RAM-based snapshot would let you cache data in RAM, with the only speed hit when memory is initially accessed.  Data would then be flushed to disk on an occasional basis.</p>
<p>You&#8217;d only get a speed benefit when accessing data that had been recently touched, though.  Good for, say, a news server, and maybe a mail server, to some extent.  It&#8217;s only a half-formed idea, in any case, and it can wait until the rest of the system is developed.</p>
<p>I have had a recurring geek fantasy of acquiring a motherboard with many gigabytes of RAM, and using that for /usr/obj/, /tmp, and perhaps /usr/ports/, just storing/refreshing it on shutdown/boot.  It&#8217;s not terribly practical now, but maybe if RAM keeps doing the eternal price slide&#8230;</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Joe "Floid" Kanowitz		</title>
		<link>https://www.dragonflydigest.com/2003/09/24/ways-to-use-up-ram/comment-page-1/#comment-10</link>

		<dc:creator><![CDATA[Joe "Floid" Kanowitz]]></dc:creator>
		<pubDate>Thu, 25 Sep 2003 13:52:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.shiningsilence.com/dbsdlog/?p=32#comment-10</guid>

					<description><![CDATA[Anyone want a headache?  I just found this while trying to refresh my memory on OpenBSD&#039;s mfs:

http://www.blackant.net/other/docs/howto-full-system-mfs.php

---

I was thinking of the softupdate delayed-commit work* when I came up with my cockamamie idea; the moment of &#039;insight&#039; was &#039;What if the delay went on forever and the actual commit to disk was never made?&#039;

To be honest, I have no idea how the snapshot ability could/would/wouldn&#039;t relate here; refreshing my memory with the papers at the bottom of http://www.mckusick.com/softdep/ just proved interesting, but my feeble mind says &quot;that&#039;s just metadata?,&quot; so if you&#039;re making a brilliant point on the interaction between that and the buffer cache(?), it&#039;s shot right over my head.**  (Maybe you&#039;re on to some other mode of filesystem-abuse for fun and profit?)

---

Did I miss something with this talk of ditching softupdates?  (Forgive me if all the overloading of the word &#039;journaling&#039; didn&#039;t inspire confidence.)  I gathered it would stop being the only way of life, might need reimplementation someplace other than it currently is, but I missed out or just plain forgot if the concept itself suddenly became old and busted.  Is there a New Hotness?  Am I reading too much into other people&#039;s acknowledgement of simple work-in-progress breakages?  Are other people reading too much into other people&#039;s acknowledgement of simple work-in-progress breakages?

---

*vfs.sync_extdelay and the code behind it.  In or planned for FreeBSD at least, can&#039;t remember where or when I&#039;ve otherwise seen it mentioned.  (Deja vu that it was mentioned on dragonfly.kernel, but if I knew where, I think I&#039;d have the answer to &#039;Do we hate softupdates now?&#039; already.)

**Emphasis on &#039;my.&#039;  Let&#039;s go shopping!]]></description>
			<content:encoded><![CDATA[<p>Anyone want a headache?  I just found this while trying to refresh my memory on OpenBSD&#8217;s mfs:</p>
<p><a href="http://www.blackant.net/other/docs/howto-full-system-mfs.php" rel="nofollow ugc">http://www.blackant.net/other/docs/howto-full-system-mfs.php</a></p>
<p>&#8212;</p>
<p>I was thinking of the softupdate delayed-commit work* when I came up with my cockamamie idea; the moment of &#8216;insight&#8217; was &#8216;What if the delay went on forever and the actual commit to disk was never made?&#8217;</p>
<p>To be honest, I have no idea how the snapshot ability could/would/wouldn&#8217;t relate here; refreshing my memory with the papers at the bottom of <a href="http://www.mckusick.com/softdep/" rel="nofollow ugc">http://www.mckusick.com/softdep/</a> just proved interesting, but my feeble mind says &#8220;that&#8217;s just metadata?,&#8221; so if you&#8217;re making a brilliant point on the interaction between that and the buffer cache(?), it&#8217;s shot right over my head.**  (Maybe you&#8217;re on to some other mode of filesystem-abuse for fun and profit?)</p>
<p>&#8212;</p>
<p>Did I miss something with this talk of ditching softupdates?  (Forgive me if all the overloading of the word &#8216;journaling&#8217; didn&#8217;t inspire confidence.)  I gathered it would stop being the only way of life, might need reimplementation someplace other than it currently is, but I missed out or just plain forgot if the concept itself suddenly became old and busted.  Is there a New Hotness?  Am I reading too much into other people&#8217;s acknowledgement of simple work-in-progress breakages?  Are other people reading too much into other people&#8217;s acknowledgement of simple work-in-progress breakages?</p>
<p>&#8212;</p>
<p>*vfs.sync_extdelay and the code behind it.  In or planned for FreeBSD at least, can&#8217;t remember where or when I&#8217;ve otherwise seen it mentioned.  (Deja vu that it was mentioned on dragonfly.kernel, but if I knew where, I think I&#8217;d have the answer to &#8216;Do we hate softupdates now?&#8217; already.)</p>
<p>**Emphasis on &#8216;my.&#8217;  Let&#8217;s go shopping!</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
